Who wants Roo to generate the look anyway?

[MiB]

I know that Roo just generates a basic look that the developer can finish themselves. However, I really feel that Roo should only generate structure (HTML) and no look (CSS) at all. Who wants all web sites to look similar or have too similar solutions ? Currently using the Roo tags give a "Roo look & feel" that I don't care for. My main problem in making Roo sites look and work the way I want is the lack of full control over the HTML structure.

I don't want premade dojo themes creeping into my interfaces. I want to make my own look. What professional outfit want premade looks to start with? The first thing I do at the GUI stage is to rip out all the stuff that gets in the way. This is currently too timeconsuming, for the newcomer at least.

I suggest to the Roo-team
1. to refocuse more on html structure rather than any kind of implementation of specific themes.
Give the Roo user more control over the generated structure. I don't care how my data looks when I'm building the backend, as long as I can see it. I care about what structure my data have. I want full control of this structure. I don't want DIVitis. I want as much semantic markup as possible.
2. Solve the problem that jspx requires elements to be closed, that are actually according to the HTML5 spec unclosed without a trailing "/", as is the case with the IMG-element for instance. If Roo supports HTML5 it should support the full range of acceptable HTML5 syntax, no?
3. Make it much easier to implement interfaces built by professionals
4. SASS / Compass support or if you have something better would be extremely useful.
5. The menu.jspx would be more useful if it was focused on building the actual navigation. I don't use the generated menu in anything, not even the administrator pages. It's only useful for the Roogenerated pages, which more and more feels simply like test pages, which is nice but has very little to do with the end production.
6. I'd rather just have Roo only generate Spring tags. If we can't have Roo tags that are actually useful , ie that are easily controllable by the user, or build an environment for users that encourages sharing of developed Roo tags that are, then why even have the tags there other than for being some kind proof of concept? I don't really use much of the Roo tags in the production site. I use the Spring tags.

I want total control of my web sites. Currently I feel the only way have that is to rip out much of the Roo GUI at the point of building the interface. Some of the time saved using Roo is lost there which is very unfortunate.

I'm sorry if I come on as being harsh, but I'm frustrated over the possibility that Roo is the wrong choice for building effective web sites. I've spent a year learning to use it. I feel that in many ways it's more efficient to just use Spring with suitable packages as it is. Am I really the only one feeling this way?

[delgad9]

Hi MiB,

Couple of requests based on your points...

1) Could you please provide link(s) of UI interfaces -examples- you are implementing with Roo.
2) What is "semantic markup"? How you implement it?


Thank you in advance
jD

[MiB]

Hi MiB,

Couple of requests based on your points...

1) Could you please provide link(s) of UI interfaces -examples- you are implementing with Roo.
2) What is "semantic markup"? How you implement it?

1) The point is that I'm not implementing them with Roo. I tried but found it cumbersome and futile. It's not about my personal style or preferences though, so I'm reluctant to give personal examples here.

2 "Semantic markup" is simply the best suited html tags for the content. You typically build and think the design starting with the content, going content-out. Others have made better examples than me.

[MiB]

jD, when you ask how I implement semantic mark up are you asking how I mark up my content or are you asking something else more Roo-related?

[hatim]

Disclaimer: I don't personally know or work with ROO team, these are just observations/ramblings. Please call me out if I am out of line.

If I am not mistaken, ROO team has spent considerable effort in making ROO extensible with the add-ons. It is conceivable that ROO addons can be written by third parties which change the behavior of ROO to the extent that its CRUS is as minimal as possible. I believe you can already do that with RESTful interfaces.

One really big problem is that technology is always a moving target while spring source has it's own corporate plans/interests to look after (hence a conflict) This has resulted in quite a stall in ROO's growth IMO.

-First in the eastly days ROO is aligned with Dojo, perhaps back in 2009 when ROO started Dojo was probably an equal competitor in terms of adoption to JQuery, but now when you mention Dojo people think you are talking about code katas (sorry site pen ppl, I love you, but this is true). If they can see the writing on the wall they should nuke the dojo implementation and start fresh with Jquery, like right now (I reckon it would still not take off if was done as a third party addon)

-Spring ROO team focused on GWT/GAE, that was a big thing for Google I/0 2010. Not so much in 2011 (i remember a question was asked at a GWT talk about it and it was deflected). It works and its all fine, but I don't feel the love

-Then Roo chose OSGI as its extension platform but this year we find @springrod's lack of enthusiasm for it (mean while an important OSGI related project aka DM_server is given out to Eclipse) signaling a strategic shift from OSGI.
So lots of things that were suppose to work out for ROO are not really top priority.

-Now there was also talk of integration with wavemaker, which would be another white elephant in my opinion (but hey, who knows it was just rumor i guess)

ROO team is doing a wonderful job with things like core architecture, spring data add-ons etc. But I think we need more stewardship in terms of add-ons in general. I have been whining about a comprehensive security add-on for like ages. (I am not expert enough to pull it off on my own). The Spring Roo in Practice guys have done a wonderful job by writing the book and it's add-ons chapter, and there are many resources for people to begin making more add-ons. But the reality is that we don't see many in the wild and the ones that are there are breaking up all the time with new releases.

We just need more experienced people who can wrestle with all the techs and make good add-ons for us mortals to consume. Or at least guide us, mentor us so we can make our own ugly but workable add-ons .

[delgad9]

Hello Hatim,

Probably you are referring Spring Roo in Action, the Manning Book... I guess.

We just need more experienced people who can wrestle with all the techs and make good add-ons for us mortals to consume. Or at least guide us, mentor us so we can make our own ugly but workable add-ons

You hit the nail on the head. How to get more experienced people interested in helping Roo to grow...

I believe one major problem is Economics. The fact that there are no sponsors or support for enabling independent developers interested in creating add ons or helping Roo growing. Likewise you publish solutions to recurrent questions a problems or issues posted in the forum, expecting a minimal donation. Getting a thank you -since you help them- coming from a colleague is always welcome but I will be better if coming with a support in a form of a donation that allow you to continue creating more solutions.

Donations are minimal per definition, less that a technical book might cost. No to mention that it won't be any book out there that will help you with your issue. At least with Spring Roo.
Unfortunately the expectation of being open source is getting everything for free.

Publish a book is impossible without connections or a good endorsement. I think I have good Spring Roo stuff for 2 or 3 intermediate and advanced books. You might ask what you include in such book(s) well: Most of my Sping Roo R & D work shown in my blog site http://pragmatikroo.blogspot.com/. Solutions to many Spring Roo forum unanswered questions and open Jira tickets.


I believe if we can turn it in a win-win situation instead of a "open source entitlement for free" mentality it will be better for all parties interested in Roo.

Thank you and B. Roogards
jD

[MiB]

jD, as I see it Open Source is about sharing the code and sharing the burden and using the end product, addon or framework, to make a sellable product or service of some sort. Addons can be created if enough people find it a common interest and find ways to share the work of developing and maintaining the source code.

You can always develop everything yourself, but that does mean you will have to do all parts and maintain the code yourself.

Some people will not do code, because they don't know how or simply don't want to. This doesn't really have to matter as long as the open source developers have a critical body of people devoted to the development tasks. They mere users can still be of assistance for finding bugs and having suggestions for improvement.

Donations are possible, but the money are more likely to come from activities where the open source code is useful and the (individual perhaps) open source developer sell a solution or teach. These projects the open source developers will have time to do because they're not alone in developing and maintaining the open source code.

[delgad9]

MiB,

In my opinion, open source is a strategy for penetrating market and getting a share of it...
Open source requires sponsors to support development teams, since the main delivery they produce is basically given for free. The sponsor companies are expecting that by providing the free software potential customers move on other services or products -like cloud foundry- which are not free.


In my case, I am an independent developer specialized only in providing solution to unresolved Spring Roo issues or very hard to find elsewhere. Sponsors and donations are valid and accepted ways to support developers in open source environment.

jD

[alexanrb]

jD,

I thought you would release your ROO jQuery plugin in December, as per your (marketing) posts.

There are other (messy) ways to generate jQuery for your front end. I am using ROO to generate all but the UI layer and use Springfuse to generate the the UI layer (sitemesh + jQuery)... although it is a little extra work, but it is far quicker than waiting for you to release your roo jQuery addon.

on your thought/dreams about hitting the jackpot with the jQuery plugin, good luck :-)

[delgad9]

Hello alexanrb,

I got the jack pot already... Two persons asked for SYNERGY in one day. Since, I made the announcement.
I am trying really hard to understand the open source heart & mind to align my efforts to it. Certainly there is an urgency for such add-on but I can't get any support for releasing it.

I really need an sponsor for releasing it in a responsible way. In the mean time, I've postponed SYNERGY a little bit. Right now, I am exploring NOSQL. It might get me the sponsor(s) that I need for continue my Spring Roo R&D for the community.

BTW thank you for asking.
B. Roogards
jD