Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Roo GWT customization

  1. #1
    Join Date
    Nov 2010
    Posts
    2

    Default Roo GWT customization

    Hello all,
    How it was established in other thread we do need documentation, examples etc on developing GWT apps from scaffolding that roo builds. In their absence I was trying to do something on my own.
    So I've messed with ui.xml, renderers and other generated stuff. I had some moderate success with it.
    At some point when roo detected some change in my entities it overrode everything I have changed in this area.
    I am a little confused here. All entities have nice separation of handwritten code that roo never touches and aj files that developers should not touch.
    But in gwt area there is no such separation. How are we supposed to develop GWT apps if we cannot touch the generated code? It maybe works nice for demo but any real life app needs customization. What am I missing here?

    Thanks a lot

  2. #2

    Default

    Hi eugenen,

    Yes It is true. I also facing this problem . If you customized your code and change any thing through roo command or in any Entities It revert back all The changes.

  3. #3

    Default

    Hi ,
    Yes I am facing Same problem. Evey Time when I change any Entities or set up any roo command it Revert back my customized code

  4. #4
    Join Date
    May 2008
    Posts
    5

    Default

    I've encountered same problem and tried to create appropriative thread in this forum, but without success. The only solution I find is to create a roo stub project as a generator of entities, finders, UI etc and copy java resources to my main project (without roo).

  5. #5
    Join Date
    Nov 2009
    Posts
    14

    Default turning off GWT support?

    Hi, is there a way to turn off Roo's GWT support after creating to project setup?

    Please assume that I'm only evaluating Roo and I'm not regular user of the technology...

    I could imagine a scenario like this:
    1., Create entities, Controllers, GWT project nature in Roo
    2., Disable GWT support, leave everything else unchanged,
    3., use the other Roo features for all the other stuff.

    Regards, Daniel

  6. #6
    Join Date
    May 2008
    Posts
    5

    Default

    I tried to find (without success) a place where Roo keeps info about previously executed commands e.g "gwt setup" to remove it from here. I think it would be cool to have some meta roo file.

  7. #7
    Join Date
    Nov 2009
    Posts
    14

    Default

    I would rather think of a "gwt disable" command -> I need it for the first step...

    As an (messy) alternative approach: some of the Roo tutorials have a preconfigured script file generating the project?

    Can I generate a GWT project called "pizza" with GWT,
    copy pizza to a temp location,
    delete pizza
    regenerate the project without GWT,
    overwrite the new structure with the "broader" GWT structure?
    (file system copy paste, without roo shell or STS)

    Would Roo tolerate a valid file system/project structure with components out of Roo -s scope?

    D

  8. #8
    Join Date
    Nov 2010
    Posts
    2

    Default

    I think that removing GWT from the project is not that difficult and can be achieved by multiple ways. Maybe the easiest would be by removing @RooGwtMirroredFrom annotation from each proxy class. This way new entities will still be managed by Roo and new set of GWT classes will be created for each new entity.
    That is not a question. The real question is how to develop real world apps with Roo without partially or fully disabling it. Roo is a great time saver and it would be useful to use it not only for generating the initial scaffolding but to maintain it too as the project evolves. Say, one adds a new field to an entity. If scaffolding is disabled all scaffolding classes related to the entity should be edited manually. I can even think of such a messy way as backing up all modified files for the entity, adding back @RooGwtMirroredFrom tag, generating new scaffolding classes based on the latest version of the entity and then manually merge new scaffolding classes with the backed up version of them. It maybe more tedious and time consuming process than manually editing each scaffolding class. It kind of defeats purpose of Roo - to minimize tediuos, error prone, repetetive tasks and focus on the application logic instead.
    It is understandable that automatic support of evolving GWT app has challenges as the client side GWT code cannot use the same approach for separating handwritten classes from the generated ones as it is done on the server side. But I guess it could be done by some different way.
    It would be very helpful if we could hear from the Roo team what is their thought on the matter.
    Last edited by eugenen; Nov 3rd, 2010 at 05:06 PM.

  9. #9
    Join Date
    Nov 2009
    Posts
    14

    Default

    Thanks for the reply, I will definitely try this out.

    My problem is, that I'cant change the existing database structure and have to provide tranformed view of it and preserv the capability to edit the original data...

    I have somethin like a key-value database in a RDBMS system: a User object has a fixed number of parameters, listed like key - value pairs...

    Table attribute looks like something this:
    User Attribute Value
    1 Height 180
    1 Weigth 80

    Unfortunately this is the best approach for represeinting this domain, but it's a pain to create the business and view tiers...

    I have managed to overcome the problem by definining an Attribute entity and a Customer POJO list whitch can be displayed by a regular view (curently in an RCP context)... the list is accessed through the business tiers interface.

    This is where Roo comes in and for the reasons above I can not simple let it generate some controller to the Attribute tables Entities and a web tier accordingly....

    I hope that I can move my project into Roo. It would help definitely a lot in the future, I will let you know if I happen to succeed.

    Thanks for the tip, best regards.

  10. #10
    Join Date
    Apr 2008
    Location
    Philadelphia, US
    Posts
    198

    Arrow

    you can vote for JIRA ROO-1641: "Remove Roo Completely from the Project with One Command"

    /Anatoly
    Humans are stateful and mutable beings that have no problems processing many things concurrently and share state with others + they are usually "coupled"

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •