Hi Oscar, I guess you were just a bit unlucky, since I was doing maintenance yesterday on the artifactory server, so it was offline for a few hours. You can try again and it should work now.
Best regards, Edwin 2016-04-25 18:22 GMT+02:00 subes <gsu...@gmail.com>: > As a status update, I have finished integrating Apache Shiro as an > alternative to Spring-Security and integrating Apache Isis as a backend > provider. > The example project can be found here: > https://github.com/subes/invesdwin-nowicket/tree/master/invesdwin-nowicket-parent/invesdwin-nowicket-examples/invesdwin-nowicket-examples-isis > You can look at the "integration" package to see the utilities I had to > create. Dunno if this suffices for an integration addon in Apache Isis, you > should decide. > > To integrate the Rest-Viewer of Apache Isis, you can just extend the > web.xml in the project. I have not tried running the Wicket-Viewer in the > same application, but I expect runtime errors because NoWicket uses Wicket > in Version 7.1.0 while Isis Wicket-Viewer uses 6.20.0. This needs to be > updated in Isis before further integration can be done since those versions > are not API compatible. > > For further integration it would be interesting to see NoWicket use the > Look and Feel of Isis Wicket-Viewer and to be able to see NoWicket Pages, > Panels and Modals directly integrated into the Wicket-Viewer. Maybe this > would be possible with the Component Factory, but I see this as a > cumbersome approach and only valid for Panels. Doing Modals or Pages (with > Menu integration) would not be possible as far as I see it. > > Best regards, > Edwin > > > 2016-04-25 18:09 GMT+02:00 subes <gsu...@gmail.com>: > >> 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! >>> >> >>> >>> >> >> >
