Hi Dan,
I had some trouble reading my mail (not sending though...) so I missed a
lot of updates on this thread. Thanks for your quick implementation! I will
look at it asap.
I think the wizard should be part of the wicket-viewer but when all
add-ons can be found on one clear website it shouldn't be a problem to make
it an add-on, though.
Erik
------------------------------
*From:* GESCONSULTOR - Óscar Bou [[email protected]]
*Sent:* Saturday, June 14, 2014 11:41 AM
*To:* [email protected]
*Subject:* Re: wizard like form
Really like a lot the idea of "isisaddons.org" for those related to
Google Maps, etc.
Not sure about considering the Wizard as an add-on like the other ones,
as probably we will mention it as one of the possible UIs that can be
generated through Isis (meaning it's really part of the "core" project).
I don't think about it as a widget/component, but a different way to
render the UI, including page navigation.
But that's really subjective, so do whatever you think is best.
Perhaps you're considering future add-ons corresponding to other UI
designs as future add-ons.
What it's really important as seems for all other mailing list users is
that you've developed it. Thanks!
Oscar
El 14/06/2014, a las 11:19, Dan Haywood <[email protected]>
escribió:
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.
* Ó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.
