New Java EE model, need feedback from plugin writers

Hi! We've created a new model for easy reading XML files like deployment
descriptors, Faces configs, etc. We've also created a GUI interface controls
for easy editing such XML-based structures. Now all our Java EE interfaces
are based on these model & controls. All of this is in OpenAPI, there's even
some documentation on it (see com.intellij.util.xml package). As an example
one can see our EJB and Faces models, and weblogic plugin. So, please, look
at it and say something.

--

Peter Gromov

Software Developer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"


45 comments

hi,

it seems, there is no explicit method to get WebModel by Module.
So, I have to make direct class casting:

WebModel model = JavaeeModuleProperties.getInstance( webModule );

Is it ok ?

Regards,
Yaroslav Sokolov.

0

It works, but using WebUtil would be better, in the next EAP we'll provide a
correct getter there.

"Yarick" <no_reply@jetbrains.com> wrote in message
news:16887792.1143731590016.JavaMail.javamailuser@localhost...

hi,

>

it seems, there is no explicit method to get WebModel by Module.
So, I have to make direct class casting:

>

WebModel model = JavaeeModuleProperties.getInstance( webModule );

>

Is it ok ?

>

Regards,
Yaroslav Sokolov.



0

Peter,

At a first glance the new model looks very promising! But currently I don't have enough control over the generated XML. For example I create an XML tag 'test' with:

 getTest();
]]>

After creating a corresponding UI and entering some value xyz, the XML gets updated correctly as xyz. After clearing the value, the empty tag ]]> remains there, but my requirement is to remove the tag completely. (In the old days of IDEA 4.5 this was achieved by calling XmlValue.setShouldDeleteIfEmpty(true);).

0

In fact, tag remaining depends on what you give to
"GenericDomValue.setValue". If it is null, then tag is removed, if it is "",
then tag is preserved with empty body. It was really a bug with Dom
controls, they gave always "". Now it's fixed, and everything works.

"Martin Fuhrer" <mf@fuhrer.com> wrote in message
news:6199956.1143783524638.JavaMail.itn@is.intellij.net...

Peter,

>

At a first glance the new model looks very promising! But currently I
don't have enough control over the generated XML. For example I create an
XML tag 'test' with:

>

 GenericDomValue getTest();
> ]]>

After creating a corresponding UI and entering some value xyz, the XML
gets updated correctly as <test>xyz</test>. After clearing the value, the
empty tag <test></test> remains there, but my requirement is to remove the
tag completely. (In the old days of IDEA 4.5 this was achieved by calling
XmlValue.setShouldDeleteIfEmpty(true);).



0

And how do I control that? Currently I simply call bindProperties() in a
class extending BasicDomElementComponent, I never call setValue() by myself.

Peter Gromov (JetBrains) wrote:

In fact, tag remaining depends on what you give to
"GenericDomValue.setValue". If it is null, then tag is removed, if it is "",
then tag is preserved with empty body. It was really a bug with Dom
controls, they gave always "". Now it's fixed, and everything works.

"Martin Fuhrer" <mf@fuhrer.com> wrote in message
news:6199956.1143783524638.JavaMail.itn@is.intellij.net...

>> Peter,
>>
>> At a first glance the new model looks very promising! But currently I
>> don't have enough control over the generated XML. For example I create an
>> XML tag 'test' with:
>>
>>

> GenericDomValue getTest();
>> ]]>

>> After creating a corresponding UI and entering some value xyz, the XML
>> gets updated correctly as xyz. After clearing the value, the >> empty tag remains there, but my requirement is to remove the >> tag completely. (In the old days of IDEA 4.5 this was achieved by calling >>]]> XmlValue.setShouldDeleteIfEmpty(true);).



--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0

You shouldn't control that, DOM UI Controls do. Should do. And in the next
EAP they will really do.

"Martin Fuhrer" <mf@fuhrer.com> wrote in message
news:e0itjg$eks$1@is.intellij.net...

And how do I control that? Currently I simply call bindProperties() in a
class extending BasicDomElementComponent, I never call setValue() by
myself.

>

Peter Gromov (JetBrains) wrote:

>> In fact, tag remaining depends on what you give to
>> "GenericDomValue.setValue". If it is null, then tag is removed, if it is
>> "", then tag is preserved with empty body. It was really a bug with Dom
>> controls, they gave always "". Now it's fixed, and everything works.
>>
>> "Martin Fuhrer" <mf@fuhrer.com> wrote in message
>> news:6199956.1143783524638.JavaMail.itn@is.intellij.net...
>>> Peter,
>>>
>>> At a first glance the new model looks very promising! But currently I
>>> don't have enough control over the generated XML. For example I create
>>> an XML tag 'test' with:
>>>
>>>

>> GenericDomValue getTest();
>>> ]]>

>>> After creating a corresponding UI and entering some value xyz, the XML
>>> gets updated correctly as xyz. After clearing the value, >>> the empty tag remains there, but my requirement is to >>> remove the tag completely. (In the old days of IDEA 4.5 this was >>> achieved by calling XmlValue.setShouldDeleteIfEmpty(true);). >> >> >]]>

--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com



0

Hi! We've created a new model for easy reading XML files like deployment
descriptors, Faces configs, etc. We've also created a GUI interface controls
for easy editing such XML-based structures. Now all our Java EE interfaces
are based on these model & controls. All of this is in OpenAPI, there's even
some documentation on it (see com.intellij.util.xml package). As an example
one can see our EJB and Faces models, and weblogic plugin. So, please, look
at it and say something.

A small article about how to use it, e.g. on http://blogs.jetbrains.com/idea/
would be very helpful and highly appreciated by everyone.

Thanks in advance,

Ahmed.

0

I'm desperately waiting... :)

Peter Gromov (JetBrains) wrote:

You shouldn't control that, DOM UI Controls do. Should do. And in the next
EAP they will really do.

"Martin Fuhrer" <mf@fuhrer.com> wrote in message
news:e0itjg$eks$1@is.intellij.net...

>> And how do I control that? Currently I simply call bindProperties() in a
>> class extending BasicDomElementComponent, I never call setValue() by
>> myself.
>>
>> Peter Gromov (JetBrains) wrote:
>>> In fact, tag remaining depends on what you give to
>>> "GenericDomValue.setValue". If it is null, then tag is removed, if it is
>>> "", then tag is preserved with empty body. It was really a bug with Dom
>>> controls, they gave always "". Now it's fixed, and everything works.
>>>
>>> "Martin Fuhrer" <mf@fuhrer.com> wrote in message
>>> news:6199956.1143783524638.JavaMail.itn@is.intellij.net...
>>>> Peter,
>>>>
>>>> At a first glance the new model looks very promising! But currently I
>>>> don't have enough control over the generated XML. For example I create
>>>> an XML tag 'test' with:
>>>>
>>>>

>>> GenericDomValue getTest();
>>>> ]]>

>>>> After creating a corresponding UI and entering some value xyz, the XML
>>>> gets updated correctly as xyz. After clearing the value, >>>> the empty tag remains there, but my requirement is to >>>> remove the tag completely. (In the old days of IDEA 4.5 this was >>>> achieved by calling XmlValue.setShouldDeleteIfEmpty(true);). >>> >> -- >> Martin Fuhrer >> Fuhrer Engineering AG >>]]> http://www.fuhrer.com



--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0

We've decided, that it would be better to have a big article on the site,
than small blog post, because DOM really has a lot of non-evident features.
So wait a bit!

"Ahmed Mohombe" <amohombe@yahoo.com> wrote in message
news:e0iubv$h5m$1@is.intellij.net...
>> Hi! We've created a new model for easy reading XML files like deployment
>> descriptors, Faces configs, etc. We've also created a GUI interface
>> controls for easy editing such XML-based structures. Now all our Java EE
>> interfaces are based on these model & controls. All of this is in
>> OpenAPI, there's even some documentation on it (see com.intellij.util.xml
>> package). As an example one can see our EJB and Faces models, and
>> weblogic plugin. So, please, look at it and say something.

A small article about how to use it, e.g. on
http://blogs.jetbrains.com/idea/
would be very helpful and highly appreciated by everyone.

>

Thanks in advance,

>

Ahmed.



0

We've decided, that it would be better to have a big article on the site,
than small blog post, because DOM really has a lot of non-evident features.

Of course that would be much better, but I didn't dared to ask a "big article" :).

So wait a bit!

Thank you. I can't wait to read it :).

Ahmed.

0

Peter,

In a deployment descriptor I have an XML attribute named 'configId'. But
by defining my interface as

GenericAttributeValue]]> getConfigId();

an attribute named 'config-id' is generated. What can I do?

Peter Gromov (JetBrains) wrote:

Hi! We've created a new model for easy reading XML files like deployment
descriptors, Faces configs, etc. We've also created a GUI interface controls
for easy editing such XML-based structures. Now all our Java EE interfaces
are based on these model & controls. All of this is in OpenAPI, there's even
some documentation on it (see com.intellij.util.xml package). As an example
one can see our EJB and Faces models, and weblogic plugin. So, please, look
at it and say something.

--

Peter Gromov

Software Developer

JetBrains, Inc

http://www.jetbrains.com

"Develop with pleasure!"


--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

0

Annotate the getter with @Attribute("configId")

"Martin Fuhrer" <mf@fuhrer.com> wrote in message
news:e1ioed$4v1$1@is.intellij.net...

Peter,

>

In a deployment descriptor I have an XML attribute named 'configId'. But
by defining my interface as

>

GenericAttributeValue<String> getConfigId();

>

an attribute named 'config-id' is generated. What can I do?

>

Peter Gromov (JetBrains) wrote:

>> Hi! We've created a new model for easy reading XML files like deployment
>> descriptors, Faces configs, etc. We've also created a GUI interface
>> controls for easy editing such XML-based structures. Now all our Java EE
>> interfaces are based on these model & controls. All of this is in
>> OpenAPI, there's even some documentation on it (see com.intellij.util.xml
>> package). As an example one can see our EJB and Faces models, and
>> weblogic plugin. So, please, look at it and say something.
>>
>> --
>>
>> Peter Gromov
>>
>> Software Developer
>>
>> JetBrains, Inc
>>
>> http://www.jetbrains.com
>>
>> "Develop with pleasure!"
>>
>>
>

--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com



0

and what is the new suggested way to get WebModel by Module using new WebUtil ?

(I did not find any in EAP-5218 neither in EAP-5231)

Regards,
Yarick.

0

We've decided, that it would be better to have a big article on the site,
than small blog post, because DOM really has a lot of non-evident features.
So wait a bit!

Any progress on this "big article"?

Thanks in advance,

Ahmed.

0

"Yarick" <no_reply@jetbrains.com> wrote in message
news:26952863.1145356378928.JavaMail.itn@is.intellij.net...

and what is the new suggested way to get WebModel by Module using new
WebUtil ?

>

(I did not find any in EAP-5218 neither in EAP-5231)


WebUtil.getWebModuleProperties(]]>).getRoot()


0

Any progress on this "big article"?


It's quite close to readiness. I'm in fact rewriting and fixing some things
in model when writing about them :). Soon...


0

>> Any progress on this "big article"?


It's quite close to readiness. I'm in fact rewriting and fixing some things
in model when writing about them :). Soon...

Great :). I hope they'll come both(article +fixes) with the next EAP build :).

Ahmed.

0

Hopefully you don't publish the article before having simplified the EJB custom editor stuff. Having to implement a PerspectiveFileEditorProvider, a PerspectiveFileEditor, etc. only to display a CommittablePanel in the end seems too much overhead to me. The old convenience method in EjbCustomPageProvider was much easier to use... :(

0

Shouldn't there be a visual editor for web.xml? I cannot seem to find it ?!!?

0

"Martin Fuhrer" <mf@fuhrer.com> wrote in message
news:29406222.1145381185411.JavaMail.itn@is.intellij.net...

Hopefully you don't publish the article before having simplified the EJB
custom editor stuff. Having to implement a PerspectiveFileEditorProvider,
a PerspectiveFileEditor, etc. only to display a CommittablePanel in the
end seems too much overhead to me. The old convenience method in
EjbCustomPageProvider was much easier to use... :(


In the old times you had to create an application/project component, extend
there anonimously EjbCustomPageProvider, create there a CommittablePanel.
Now. You should create application component PerspectiveFileEditorProvider,
there you create your CommittablePanel and an anonimous DomFileEditor (in
simple cases not even anonimous, just call
DomFileEditor.createDomFileEditor()). I think that this is equally easy, the
number of needed classes doesn't differ. Instead you get a possibility to
change the editor tab placement and to display a caption.


0

At some moment it didn't open, now it should. Double-click on Web module
node in Java EE project view.

"Yann Cebron" <no_reply@jetbrains.com> wrote in message
news:23994277.1145382733467.JavaMail.itn@is.intellij.net...

Shouldn't there be a visual editor for web.xml? I cannot seem to find it
?!!?



0

Peter Gromov (JetBrains) wrote:

Double-click on Web module
node in Java EE project view.


That currently navigates to the project view. (build 5231 w/ weblogic 8.1 web module)

Double clicking on the web.xml file simply opens the file in the editor pane as an xml file.

For consistency with other visual editors like the ant visualizer plugin, there should be
tabs at the bottom of the web.xml file editor pane to switch between visual and text editing.

0

That currently navigates to the project view. (build 5231 w/ weblogic 8.1
web module)


Very strange, should work. I'll take a look.

Double clicking on the web.xml file simply opens the file in the editor
pane as an xml file.

>

For consistency with other visual editors like the ant visualizer plugin,
there should be tabs at the bottom of the web.xml file editor pane to
switch between visual and text editing.

In fact the editor wasn't connected with web.xml text editor. In EJB module
this is correct, because one XML file describes many beans and each of them
has separate editor with several tabs. In Web module the XML also describes
main settings and many servlets. I can combine main-settings-editor with the
text editor, but is it consistent?


0

Peter Gromov (JetBrains) wrote:

In fact the editor wasn't connected with web.xml text editor. In EJB module
this is correct, because one XML file describes many beans and each of them
has separate editor with several tabs. In Web module the XML also describes
main settings and many servlets. I can combine main-settings-editor with the
text editor, but is it consistent?

Oh yeah, I forgot about that.
If the visual editor doesn't provide the ability to edit the entire file then it certainly
should not be the default editor for that file. If there were visual editors for each part
of the file, then they could all be made tabs of the text editor.

Since the deployment descriptor is actually a configuration file, perhaps it makes more
sense to make the visual editor part of the Web Module Settings. It always seemed a bit
strange where it was. Either way, access to it should be made obvious. Not accessible only
by a double-click on a tree node.

0

"Tim Haley" <ymaraner@yahoo.com> wrote in message
news:e25c7d$qs1$1@is.intellij.net...

Peter Gromov (JetBrains) wrote:

>> In fact the editor wasn't connected with web.xml text editor. In EJB
>> module this is correct, because one XML file describes many beans and
>> each of them has separate editor with several tabs. In Web module the XML
>> also describes main settings and many servlets. I can combine
>> main-settings-editor with the text editor, but is it consistent?

Oh yeah, I forgot about that.
If the visual editor doesn't provide the ability to edit the entire file
then it certainly should not be the default editor for that file. If
there were visual editors for each part of the file, then they could all
be made tabs of the text editor.

Even if there's a variable number of them, e.g. servlets?

Since the deployment descriptor is actually a configuration file, perhaps
it makes more sense to make the visual editor part of the Web Module
Settings. It always seemed a bit strange where it was. Either way,
access to it should be made obvious. Not accessible only by a
double-click on a tree node.

Any suggestions?


0

OK, I agree, it's not that complicated. But then why do you need 200 lines of code to implement it for Weblogic?

By the way: You should move JavaeeModuleAsVirtualFile and ServletAsVirtualFile to OpenAPI.

0

OK, I agree, it's not that complicated. But then why do you need 200 lines
of code to implement it for Weblogic?


Because the editor for Weblogic is very nontipical. At first, it edits two
files' fragments on one page. Then, it can edit DOM elements that don't
correspond to the real file: they are created there only after the user has
typed something in the editor page. So I have to deal with mock values,
catch Undo in them, on commit() copy them to the file, stop catching Undo...
Not very pleasant, I'd say. So the code is not very pleasant looking.

By the way: You should move JavaeeModuleAsVirtualFile and
ServletAsVirtualFile to OpenAPI.


Moved. Thanks.


0

Oh I think it isn't such an untypical editor. I will have to implement some similar editors. Therefore I was hoping that you could move the ugly parts into some common base class which I could reuse... :)

0

Oh I think it isn't such an untypical editor. I will have to implement
some similar editors. Therefore I was hoping that you could move the ugly
parts into some common base class which I could reuse... :)


Similar in both features (2 sources, mock elements)?


0

Oh I think it isn't such an untypical editor. I

will have to implement

some similar editors. Therefore I was hoping that

you could move the ugly

parts into some common base class which I could

reuse... :)

Similar in both features (2 sources, mock elements)?


Yes, both of them.

0

Please sign in to leave a comment.