Custom WebScaffold MetadataListener

I know guys you have plan to add GWT/Flex support in Roo 2.0.
But we do not want to wait :-) And we are building custom Web UI generation plugin for Dojo toolkit. It is way different with what you have now mixing JSPX/JSTL/Tiles2/SpringMVC and some Ajax'fing via Dojo. We build pure HTML Web 2.0 Dojo based reusable components for scaffolding backed by JSON-RPC exposed services.

The way we do it now is a bit cumbersome. We took standard JspMetadataListener & Co as an example and created custom DojoMetadataListener (with supported classes) which behaves very similar except it generated different output.

It works, but we have a lot of duplication code borrowed from original JspMetadataListener for doing stuff like implementing MetadataProvider and MetadataNotificationListener. I mean most of the operations like creating WebScaffoldMetadata are very similar between your JspMetadataListener, our DojoMetadataListener and (I guess) proposed GwtMetadataListener and FlexMetadataListener.

Do you guys have anything in mind in order to create something abstract to help develop custom UI Generators w/o doing much of the duplications? Or what ideas are?

Thanks!

Hi Roman

So you're looking at using GWT/Flex or sticking with Dojo?

GWT is one of my favourite UI technologies, and as such it's one of my priorities to support it in 2010. I know my colleague Jeremy Grelle is working on Roo Flex support already. I have some specific ideas on how to tackle GWT and I expect it will be quite different from the way the current web tier add-ons work.

Re abstractions of the existing web tier add-ons, I'll leave that to Stefan to comment as he wrote those add-ons. You might like to consider sending Stefan off-list what you've written so he can see the overlap. That might help with extracting common cases into a shared module. Again, though, I'll leave it to Stefan to comment.

Agree. I expect to see GWT to be different from JSP generator and be much like of existing WebController style, cause GWT is Java. But Flex UI most likely will be very similar to one we have now for JSPs.

Just wondering if Stefan has ideas about how UI generators abstraction for things like MetadataProvider/MetadataNotificationListener should looks like in the future. Or whether this abstraction is possible at all.

I thought you guys want to create specific AbstractMetadataProvider to accumulate common logic for UI generators. Just like you have AbstractItdMetadataProvider for common functionality used by ITD-based generators.

Fluff goes here. [skip this :-)]
btw, yes we kinda stick with Dojo. Non of our Fortune 500 clients allow using Flex inside their enterprise due to closed sources and vendor lock-in. While GWT is kinda weak, due to failed idea in the core. How possibly you can generate something good from static language (Java) into way more powerful language (JavaScript). It is like generate C++ code from x86 Assembler. GXT is a bit more interesting on the scene due to rich and polished UI component set and related MVC client (browser) side ideas.

Hi Roman,

I am not sure a AbstractMetadataProvider would be all that useful for Web based add-ons as there are simply too many moving parts and very little overlap in concepts (ie there are not many common parts between Flex, GWT, JSP/MVC). So I think if you want to develop an addon for the generation of web artifacts it is best that you first identify which technology you are planning to use:

1. If you are planning on using GWT you would take a look at the controller addon and learn how things are done there.

2. If you are planning to do a Flex addon I would take a look at the Roo JSP addon (look into JspMetadataListener which is triggered by @RooWebScaffold in the controller). As a starting point you could create a new annotation like @RooFlexScaffold and use that as a trigger for your own listener. You could then leverage the existing REST functionality that is generated inside the controllers to handle your requests/responses.

3. If you want to extend the functionality of the current JSP addon we recommend for you to wait until after Roo 1.0 GA is released as we will then review this addon to see how we can allow for easier extensions, etc. Ideas on this are aggregated under the ROO-8 Jira ticket (and sub tasks) and your input there is very welcome. Alternatively you can roll your own addon as explained in point 2 above.

HTH,

Stefan

Quote:

---

Originally Posted by romankuzmik

btw, yes we kinda stick with Dojo. Non of our Fortune 500 clients allow using Flex inside their enterprise due to closed sources and vendor lock-in. While GWT is kinda weak, due to failed idea in the core. How possibly you can generate something good from static language (Java) into way more powerful language (JavaScript). It is like generate C++ code from x86 Assembler. GXT is a bit more interesting on the scene due to rich and polished UI component set and related MVC client (browser) side ideas.

---

I think it's worth thinking about it from the GWT project's perspective. They're totally devoted to performance, payload size and user experience. That's quite different from what tools like GXT aim to do, which is to make attractive widgets that a developer can use easily. I personally prefer a "serious" engineering focus on compilers and getting the foundation solid before branching out into UI. We did the same "focus on a solid core first" with Roo, and the add-ons come later. I suspect in the long term we'll see a lot more GWT. It doesn't have the closed source problem and the compiled applications are getting better and better, especially in GWT 2.0. Plus I quite like the fact a user can see common HTML controls and know how to interact with them. It reduces the conceptual weight and enhances usability to give users what they're familiar with. That's why I'm a GWT fan, although I do acknowledge it takes more effort to build an enterprise app with GWT as of this moment in time than would be ideal. That's where Roo can come in and help out a lot: deliver serious productivity to GWT without compromising on its solid engineering fundamentals. That's something I get excited about. :-)

1. In order to trigger custom Web UI generators I have to create my own MetadataNotificationListener and make it listen on CUSTOM Metadata in upstream. Right? Out of the box it means:

@RooWebScaffold -> JspMetadataListener

So, if I need my custom DojoMetadataListener to take care of UI I need to replace @RooWebScaffold with something like @RooDojoScaffold. In its turn it means 'controller' command should be able to manage correct type of the scaffold respectively.

For instance:

controller --type=jsp|flex|gwt|<any custom string>

will generate

jsp -> @RooWebScaffold
flex -> @RooFlexScaffold
anystring-> @RooAnystringScaffold

Alternatively you probably can do:

jsp -> @RooWebScaffold(type=RooWebScaffold.JSP)
flex -> @RooWebScaffold(type=RooWebScaffold.FLEX)
anystring-> @RooWebScaffold(type="anystring")

Without corresponding ControllerCommands extension in place, I do not think you can write custom UI generator today. Or am I missing something? For now I just listen on @RooWebScaffold and result is JSP generation (caused it is configured out of the box and i cannot turn it off) and my custom Dojo generation which uses separate folder structure for its output.

2. About REST functionality. It would be nice to have content negotiation protocol configured for all controllers right of the box with xml and json. Or at least have an option on 'controller' command to enable it.

3. At least nofity() in JspMetadataListener and in AbstractItdMetadataProvider are all about the same. They are identical except downstream metadata identifier type. Basically it is template method with downstream metadata identifier type as a parameter.

Yes the way you describe it is about correct. You have shell commands which introduce annotations to target types which in turn trigger the Roo metadata system and any listeners interested in a particular annotation. So your addon could ship its own annotation @RooXYScaffold to trigger the generation of all relevant artifacts of the XY technology.

You are asking about the extension of the currect controller commands to allow for integration with other technologies. On this I would suggest for you to create your own command where you have complete freedom to add your own attributes at any time. This will keep a clear separation between the different addons (ie the current Web Controller addon does not need to be aware of JSP, Flex, Freemarker, ...XY) and therefore you don't need to rely on us updating the controller command to suit your own addon.

So you in your addon you could have a command 'dojo view' or something which adds a @RooDojoScaffold to a controller. Then you listen to this annotation and act upon its appearance. Remember the advantage of using this annotation is that users don't have to use the shell to generate artifacts, they could just as well manually add this annotation into the controller source code. Roo would still trigger the metadata model and update all listeners for this annotation.

About the REST functionality, we have been prototyping a few things and the content negotiation features in Spring 3 certainly work. It is on our todo list to integrate this as a new feature post the Roo 1 GA release.

HTH,
Stefan