OK, have implemented ISIS-807 [1], which refactors the implementation into a separate component.
I've also raised ISIS-810 [2], which removes the component from Isis; but since we aren't yet decided on whether we want this component in or out, have only pushed that as a branch, not to master. Meanwhile, I have also created a new github repo to house this component if we decide to keep it outside of Isis, see [1] ~~~ Related, yesterday Jeroen and I created a new github account, "isisaddons" [4], as a place to hold future add-ons. All of my various github projects could either move or be forked there. We've also grabbed "isisaddons.org" as a domain if we decide to follow the approach taken by Apache Wicket with their wicketstuff.org companion project [5]. ~~~ Thoughts on any of this welcome Dan [1] https://issues.apache.org/jira/browse/ISIS-807 [2] https://issues.apache.org/jira/browse/ISIS-810 [3] https://github.com/danhaywood/isis-wicket-wizard [4] https://github.com/isisaddons [5] http://wicketstuff.org/ On 13 June 2014 19:52, GESCONSULTOR - Óscar Bou <[email protected]> wrote: > > But if the annotations are part of the "Isis model", shouldn't be a > default implementation included on the free Viewer? > > Independently, the implementation could be replaceable / pluggeable with a > custom one, just as any other components. > > But at least one should be included by default. > > I also think that it adds quite points to the quickstart demo, as it's an > alternative design to usual Isis UI. > But that's completely subjective, of course :-)) > > HTH, > > Oscar > > > > > > El 13/06/2014, a las 13:27, Dan Haywood <[email protected]> > escribió: > > > Further improvements committed, tickets ISIS-781 and ISIS-800 marked as > resolved > > > Discussing off-line with Jeroen, do have some further refactorings planned, > however. Specifically: > > ... currently support for IWizard is "hard-coded" into the Wicket viewer; > it ought to be a pluggable component (such as the map and calendar > components). So will probably move it out and into a separate github repo. > > One consequence of that is that the quickstart todo app can't demonstrate > the usage. So I'll need to move that into a github repo as a separate > demo. > > One upside is that this ought to then plug into 1.5.0, rather than relying > on a new release of Isis. Also, it'll be a good resource for how to write > custom components to the Wicket viewer. > > But the basic functionality will be as currently implemented. > > More to follow.... > > Dan > > > > On 12 June 2014 20:34, Dan Haywood <[email protected]> wrote: > > OK, I've done a first-pass implementation of both: > > * ISIS-781: editable view models, and > * ISIS-800: wizards > > for the first, the view model must implement ViewModel.Cloneable. The way > it works is that the view model is immutable so far as the rest of the > framework is concerned, but (by implementing the Cloneable interface) when > the view model is next re-rendered it is actually the clone. > > for the second, the view model must implement Wizard. This is actually a > sub-interface of ViewModel.Cloneable that defines next, previous and finish > methods. > > The todo/quickstart app has been updated to use this feature; see > ToDoItemWizard. See also the cool use of contributed actions through the > "Categorized" interface that contributes both to ToDoItemWizard and also > the ToDoItem entity. > > ~~~ > The design as it stands does mean there's a little bit of boilerplate to > implement these various methods, but what we now have is probably good > enough to ship in the next release. > > Any feedback welcome > > Dan > > > > On 10 June 2014 13:16, Dan Haywood <[email protected]> wrote: > > > > > On 10 June 2014 13:09, Erik de Hair <[email protected]> wrote: > > The action (on a domain object) has the following code: > > CreateSubscriptionViewModel viewModel = new > CreateSubscriptionViewModel(); // or getContainer.newViewModelInstance.... > viewModel.viewModelInit(newSubscription.title()); > viewModel.setSubscription(newSubscripiton); // newSubscription is a > newTransientObject created earlier > return viewModel; > > > > > > I put the newSubscription in the viewmodel because I need this > subscription in a later step to add some more data to it. But getting the > subscription (or a property) for the ViewModel rendering gives a null > pointer exception. > > > A stack trace would be useful. > > But just to check: you have configured the MementoServiceDefault and the > BookmarkServiceDefault ? > > > > > I looked at the ToDoItem examples and Dileepa's code. I can see no > conceptual difference except that ToDoItem uses persisted entities and > Dileepa only sets the memento and does not pass more 'complex' objects in > the ViewModel. Do the objects have to be serializable or do I miss > something else? > > > This is probably the issue. Making the object serializable might solve > things, but it's rather unpalatable. > > Rather than creating a transient object, instead have the wizard store > the state (ie the builder pattern), and only create (and persist) the > object when done. > > ~~~ > Isis does, in fact, have the ability to create serializable mementos even > from non-serializable transient objects (a left over from the days when > Isis' architecture was client/server); but this isn't currently exposed in > a user-friendly applib service. > > We could look to doing so if the above approach is unpalatable, eg as an > extension of MementoService. > > Dan > > > > > > > Any idea? > > On 06/10/2014 12:07 PM, Dan Haywood wrote: > > On 10 June 2014 10:52, Erik de Hair <[email protected]><mailto:[email protected] > <[email protected]>> > wrote: > > > > Hi Dan, > > That's not the answer I hoped for ;-) > > > > > sorry bout that! > > > > > It looks like the ViewModels only work with persisted entities. Is that > correct? > > > > > Not exactly. A view model can hold references to any data; that's what > the > MementoService is for. > > Our Google Summer of Coder (Dileepa) has written a view model that wraps > some JSON representing a gmail obtained via a web service, for example. > > Fundamentally a view model just has the ability to marshall itself > to/from > a string. We use that string as its OID, which appears in the URL. When > we next interact with the view model, Isis recreates the view model from > that OID. What the view model does with its string is up to it. > > > > > > > What I try to accomplish right now (as a work around) is to return a > ViewModel from an action with the posted data from the action put into > that > viewmodel and than call some actions on that viewmodel. If it is possible > to return a fresh viewmodel every time I return from an action, it looks > a > bit like a wizard. At least I can build some data model in memory and > persist this model when ready. Should that be possible? > > > > > Yup, that's the best we can offer for now. > > > > > > I will elaborate my wishes in the ticket you raised. > > Wat is the use of a @NotPersistable-entity like described in [1]? > > > > > It was a way of saying that an object can never be persisted, ie a domain > constraint. But when using JDO objectstore it is somewhat redundant (or > at > least not fully implemented), because we delegate the responsibility for > doing persistence to JDO/DN. > > When Isis 2.0 comes along, some of these older annotations might end up > being deprecated/removed. > > Cheers > Dan > > > > > > Thanks, > Erik > > [1] > > > http://isis.apache.org/more-advanced-topics/how-to-07-040-How-to-specify-that-an-object-should-not-be-persisted.html > > > On 06/09/2014 07:59 AM, Dan Haywood wrote: > > Hi Erik, > Short answer is that we don't really (properly) support this. And we > should. > > I agree that @NotPersistable is confusing and its not clear what to use; > the right solution would be to implement a view model (currently: > implement > the ViewModel interface), and then - optionally - write a custom > ComponentFactory for the Wicket viewer to render the wizard > appropriately. > > But the snag even with the above is that (currently) view models are > immutable; they support actions but their properties cannot be edited. > > I can see the way forward on this; I don't think it's difficult, but it > will require a change in core and probably the wicket viewer also. > > If you want then raise a ticket for this requirement, and sketch how > you'd > like it to work. > > Cheers > Dan > > > > On 6 June 2014 17:40, Erik de Hair <[email protected]><mailto:[email protected] > > <mailto:[email protected]><mailto:[email protected]> > > wrote: > > > > Ok, I've found the @NotPersistable annotation but don't know how to use > this. I get an error message saying the object is not persistent. > Extended > my entity from AbstractDomainObject later, but that doesn't help. > > Erik > > On 06/06/2014 04:07 PM, Erik de Hair wrote: > > Hi, > > Is it in some way possible to create a wizard like form or open an action > with an action? I tried to return a not yet persisted object from an > action > and hoped I could edit some properties and add some elements to > collections > of the object before persisting it to the database... > > Thanks, > Erik > > > > > > > > > > > > > > > > > > > > > Óscar Bou Bou > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > 902 900 231 / 620 267 520 > http://www.twitter.com/oscarbou > > http://es.linkedin.com/in/oscarbou > > http://www.GesConsultor.com <http://www.gesconsultor.com/> > > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos > contienen información reservada que no puede ser difundida. Si usted ha > recibido este correo por error, tenga la amabilidad de eliminarlo de su > sistema y avisar al remitente mediante reenvío a su dirección electrónica; > no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en > un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos > de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un > escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente > dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - > 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). > Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos > adjuntos no contengan virus informáticos, y en caso que los tuvieran > eliminarlos. > > > > > >
