Please take a look also on https://github.com/brix-cms/brix-cms/wiki
On Fri, Apr 26, 2013 at 9:38 AM, Andrew Schetinin <ascheti...@gmail.com>wrote: > Hi Martin, > > See inside... > > On Fri, Apr 26, 2013 at 10:01 AM, Martin Grigorov <mgrigo...@apache.org > >wrote: > > > Hi Andrew, > > > > On Fri, Apr 26, 2013 at 7:13 AM, Andrew Schetinin <ascheti...@gmail.com > > >wrote: > > > > > In our case, we had to implement the second option, suitable for our > > needs > > > > Can you explain what do you mean by "suitable for our needs" ? > > From your message above this phrase it seems RAD/CRUD are something > > universal that will fit any needs. But then you say _our needs_ ... > > > > We have a pretty basic framework that allows defining an edit form logic in > Java without touching any HTML, and the HTML is generated automatically > from common blocks. > The idea is basic and universal, but the implementation is relatively > tightly coupled with the back-end, and making it more generic (or even > open-sourcing it) requires significant efforts - not something we can do at > this stage. > > This is the reason why there are no such at the moment. Or at least not > > widely used. > > > > That's right - it requires a lot of efforts to maintain any framework. From > the other side - consider Rails and Grails - they do have to have RAD GUI > and they are very successful mostly because of that fact. > > - http://isis.apache.org/ (see it Wicket Viewer) (very well maintained. > I > > > have no information how many users it has) > > > > I considered this one for one of the last projects, but found its > documentation lacking, and decided it is not enough supported. > > > > Then you will figure out that Ruby/Groovy performance is not that good > and > > you will have to reimplement your prototype with something else ... > > > > > Well, that's a holy war topic :-) I better will not touch it :-) > > Regards, > > Andrew > > -- > Andrew Schetinin >