Forwarding to UserList, since I forgot that on last reply. See answer below.
---------- Forwarded message ---------- From: subes <gsu...@gmail.com> Date: 2016-04-17 18:49 GMT+02:00 Subject: Re: HTML and Binding generator for Wicket built on top of Wicket-Bootstrap To: Óscar Bou - GOVERTIS <o....@govertis.com> Hi Oscar, an interesting idea, though as far as I see it the Apache Isis metamodel is more elaborate than that of NoWicket. Also it is driven by the idea of creating an UI for persistent objects without direct access to the UI coding, so persistency topics are handled in the Apache Isis annotations and method semantics and everything is expressed in the Apache Isis metamodel. Also the programming model is different, with Apache Isis you just code your model, then run the application to see the interactive results for general purpose CRUD views. With NoWicket you actually generate the HTML file, then refine the markup and Wicket page class to get a customized UI as you desire. Nothing prevents one to create a NoWicket UI on top of an Apache Isis domain entities model by leveraging the Document-View-Pattern. Just introducing "Document" classes as NoWicket UI models to callback, reuse, modify, extend, facade the domain entities to suit your custom view expectations. Since the Apache Isis metamodel is independent of any layer on top of it, this should be feasible without any framework translation in between. One could maybe even mix the auto generated UI from Apache Isis and some custom UIs with NoWicket. Though I have to confess that I am not an expert in the Apache Isis metamodel, thus if you have a different view on this topic, I would be glad to be enlightened. :) Maybe we could build some sort of proof of concept for an integration and see what addon could be created to make this interoperability easier, like a set of utility methods or something to talk to the Apache Isis semantics easier. Though my first impression would be that not much should be needed to accomplish this. I guess NoWicket could be a benefit as an addon for custom UIs next to the Apache Isis Wicket Viewer or am I wrong here? Best regards, Edwin 2016-04-17 15:59 GMT+02:00 Óscar Bou - GOVERTIS <o....@govertis.com>: > Hi there also! > > As Dan said, it’s really a pity you did that as a separate framework. > > I’ve been navigating your website and noticed it’s an amazing work on the > UI side. > You have really advanced use cases like Wizards that could be of great > help for all the Apache Isis community. > > In fact, as far as I can see, you’re deriving the UI via Java Inspection. > If instead of that, you would use the Apache Isis metamodel [1] it would > not take any longer to have all those capabilities for Apache Isis. > > Why don’t you consider to add your effort to our community, instead of > creating a new, disgregated one? > > This is an open one, so I’m pretty sure you would be really welcome, as > Dan suggested. > > You excel on deriving the UI from the (Java) metamodel. > > > Apache Isis excels on working at its opinionated work at the Domain level, > managing the Business Logic, by integrating the Metamodel, directly > supporting unit & integration tests, REST APIs (Swagger, RESTFul Objects, > …), (JAXB) View Models, etc. > > > Perhaps there would be a way to support the Apache Isis metamodel on your > framework. > > What do you think? > > It could be great :) > > Cheers, > > Oscar > > > [1] > > > > > El 17 abr 2016, a las 15:40, Dan Haywood <d...@haywood-associates.co.uk> > escribió: > > > > Nice to see another naked objects framework out there, just a shame that > > you've built this separately from our community. It would have been nice > > to have your Wicket skills to allow us to take our own Wicket viewer > > further. > > > > With respect to your request, I do take issue with some of the things you > > claim on your website [1] about the Apache Isis framework; however the > main > > point is that the frameworks aren't that comparable because they have > > different scopes/objectives. > > > > For myself I would prefer that you don't have this comparison on your > > website, ie remove the fragment "In comparison to other naked objects > > frameworks like Apache Isis, ". What remains are then reasonable > > statements about your framework. But by including that fragment it > > suggests that the Apache Isis framework doesn't offer these benefits; I > > would say that it does. > > > > What you could do instead is include links to other implementations of > the > > naked objects pattern (Apache Isis and OpenXava are the two main ones for > > the JVM, I believe). Perhaps you might say that these other > > implementations have different scopes/objectives, and then let the reader > > can judge for themselves? > > > > All that said, best of luck; as I say it's nice to have other > > implementations out there and it helps to have some friendly competition. > > > > Thx > > Dan > > > > PS: the second diagram on [2] comes from an old naked objects slide > deck; I > > think that Richard Pawson drew it originally. Could you redraw it > > yourselves, please (or obtain Richard's permission to use it)? > > > > > > [1] http://invesdwin.de/nowicket/introduction?0 > > [2] http://invesdwin.de/nowicket/concept?2 > > > > > > > > > > > > > > On 12 April 2016 at 14:55, subes <gsu...@gmail.com> wrote: > > > >> Hi there, I have a framework to announce that was built on top of Wicket > >> and Wicket-Bootstrap. It applies the Naked Objects pattern to generate > HTML > >> files and the corresponding Wicket Binding for you based on your models. > >> All the while allowing you to fully stay in control and be able to do > what > >> you are used to with Wicket and the components provided by > >> Wicket-Bootstrap. > >> > >> More info at the documentation website: http://invesdwin.de/nowicket/ > >> And on GitHub: https://github.com/subes/invesdwin-nowicket > >> > >> In the documentation I am talking about the difference to Apache Isis. > >> Mainly the difference is that NoWicket does not aim at going as deep as > the > >> persistence layer for the models and does not want to be a full CRUD > >> framework. Also explaining what disadvantages that would have for > wanting > >> to stay in control. With NoWicket you actually still have your HTML > files > >> to edit and the Wicket Page and Panel implementations you can customize. > >> NoWicket just automates the boring coding for most needs and reduces the > >> amount of SLOC to write by a magnitude. > >> > >> Could you please check that I make no claims about Apache Isis that > >> are incorrect? > >> > >> Thanks! > >> > >
