On 25 May 2016 at 06:41, Óscar Bou - GOVERTIS <o.bou@govertis.com> wrote:

Not sure if at the “core” level, currently property value changes are also managed the same way as an Action execution “intent”. Perhaps not? That was not clear to me with current changes.

Yes, at the "core" a property edit is now treated very similarly to an action with a single parameter.  In 1.13.0-SNAPSHOT it is possible to create commands for properties (ok, that was there before, but I hacked in the feature), and also to publish property edits

The terminology I've used within the framework is that these are "Member executions"... an "action invocation" and "property edit" are subtypes of this.  In fact, the new Interaction object in the applib has all of these as actual types (MemberExecution, ActionInvocation, PropertyEdit).




El 25 may 2016, a las 7:14, Dan Haywood <dan@haywood-associates.co.uk> escribió:

Well, editing is enabled by default, so CRUD is supported.  We certainly
don't want to make the framework deliberately difficult to use.

I think the best thing for me to say is that editing properties is a
work-in-progress, and where we're aiming to get to is a JIRA-like
look-n-feel.  If it works well enough for that app, then I think it should
suffice for Isis too.


On 25 May 2016 at 03:36, Stephen Cameron <steve.cameron.62@gmail.com> wrote:

I know this has been discussed previously, but it seems such a central
thing that I have to add my two-bits worth again.

Re: "it positions the framework away from the common perception of it being
a CRUD framework;"

Any database application is at its core a CRUD application, unless its view
only. So the key thing, surely, is to show people how much more Isis can do
and how easily. It seems you want to be deliberately unfamiliar to users in
order to show that its different to those other 'CRUD in five minutes'

Making a group of properties read-only and providing an action to update
all the properties together is a useful pattern, but you seem to be
suggesting that this is the right way to do it everywhere because Estatio
is done that way.

I think the in-situ editing will be good as a default behaviour.

On the upside, I think Isis is now a very sweet framework to use in many,
many aspects. There is still alot for me to learn, but I am keen to do
that, and try to convince others of its merits too.


On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <dan@haywood-associates.co.uk


Hi Hector,
welcome to the users@ mailing list.

I'm afraid that there isn't a setting to go back to the previous
but there are some good reasons - some practical, some more
philosophical -
why this change has been made.

The practical reason is that with tabs, it's not particularly clear what
global edit should be... should it be for all properties, including those
not visible on other tabs?  or should it somehow disable being able to
switch tabs when in edit mode? or perhaps there should be not a global
but instead an edit per fieldset/member group?  It wasn't at all clear
which was preferable.

Second, we've had a ticket knocking around for a while to move editing
towards that in JIRA, where one clicks in the field and then can do an
in-situ edit.  The current implementation isn't quite a slick as that,
the number of clicks is actually the same.

The philosophical reason is that, actually, it positions the framework
from the common perception of it being a CRUD framework; instead it is
for (even mostly for) complex domains where the is significant business
logic to transition from one state of the system to another.  When Jeroen
was implementing Estatio [1] he deliberately made all fields read-only
stark contrast to the packaged application it replaced), not because
wasn't a requirement to allow the data to be changed, but instead he
the business users to come back to him and explain WHY the data should be
changed.  (For example, changing the end of a tenancy date has impact
elsewhere).  So it helped us get a deeper insight into the domain, and we
encoded that insight into actions.

For the big Naked Objects system in Ireland, we also only have actions,
edits... eg award a pension claim or disallow a jobseekers allowance
claim.  Even for small stuff, eg a customer wants to change their phone
number, then this is an action because we then want to retain the old
address on file in a list of previous phone numbers. Again, the action
helps capture the intent.

If you want to allow an object's properties to be changed in bulk, then I
recommend that you add an action that accepts all the fields, and
that action on a top-level panel.  We do this for the contactapp [2].
your remaining more complex objects, I suggest that you sprinkle in some
tabs, by way of recompense.

Hope that helps


[1] http://github.com/estatio/estatio
[2] http://github.com/incodehq/contactapp

On 23 May 2016 at 21:13, Hector Fabio Meza <hector.meza@smartools.com.co



My company has been working on an Isis application in the last few
months, and after the changes to the edit functionality on 1.12.0, our
test users are asking if it's possible to put the whole form in edit
mode instead of doing it field by field.

Is there a way to tell the wicket viewer to use the previous behavior,
i.e. an edit button that affects the whole form?

Thank you.

Hector Fabio Meza Martínez
R&D Leader
www.smartools.com.co [1]

[1] http://www.smartools.com.co

Óscar Bou Bou
Socio - IT & GRC Management Services Director

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 GOVERTIS ADVISORY SERVICES, 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: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia,  y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.