You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Hector Fabio Meza <he...@smartools.com.co> on 2016/05/23 20:13:57 UTC
Edit modes in Apache Isis
Hi,
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]
Links:
------
[1] http://www.smartools.com.co
Re: Edit modes in Apache Isis
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Nice :))
Was thinking about it some days ago and had the intent to verify it when reviewing the new code.
So many changes, all oriented towards clarifying and standarizing how Isis internals works for all us.
Nice work!
Cheers,
Oscar
> El 25 may 2016, a las 7:54, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
>
>
> On 25 May 2016 at 06:41, Óscar Bou - GOVERTIS <o.bou@govertis.com <ma...@govertis.com>> wrote:
>
> @Dan
> 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).
>
> Thx
> Dan
>
>
>
>
>
>
>
>
> Regards,
>
> Oscar
>
>
>
>
>> El 25 may 2016, a las 7:14, Dan Haywood <dan@haywood-associates.co.uk <ma...@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.
>>
>> Thx
>> Dan
>>
>>
>>
>> On 25 May 2016 at 03:36, Stephen Cameron <steve.cameron.62@gmail.com <ma...@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'
>>> frameworks.
>>>
>>> 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.
>>>
>>> Cheers
>>> Steve
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <dan@haywood-associates.co.uk <ma...@haywood-associates.co.uk>
>>>>
>>> wrote:
>>>
>>>> Hi Hector,
>>>> welcome to the users@ mailing list.
>>>>
>>>> I'm afraid that there isn't a setting to go back to the previous
>>> behaviour,
>>>> 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
>>> a
>>>> 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
>>> edit
>>>> 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,
>>> but
>>>> the number of clicks is actually the same.
>>>>
>>>> The philosophical reason is that, actually, it positions the framework
>>> away
>>>> from the common perception of it being a CRUD framework; instead it is
>>> also
>>>> 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
>>> (in
>>>> stark contrast to the packaged application it replaced), not because
>>> there
>>>> wasn't a requirement to allow the data to be changed, but instead he
>>> wanted
>>>> 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,
>>> no
>>>> 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
>>> position
>>>> that action on a top-level panel. We do this for the contactapp [2].
>>> For
>>>> your remaining more complex objects, I suggest that you sprinkle in some
>>>> tabs, by way of recompense.
>>>>
>>>>
>>>> Hope that helps
>>>>
>>>> Dan
>>>>
>>>> [1] http://github.com/estatio/estatio <http://github.com/estatio/estatio>
>>>> [2] http://github.com/incodehq/contactapp <http://github.com/incodehq/contactapp>
>>>>
>>>>
>>>>
>>>> On 23 May 2016 at 21:13, Hector Fabio Meza <hector.meza@smartools.com.co <ma...@smartools.com.co>
>>>>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> 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 <http://www.smartools.com.co/> [1]
>>>>>
>>>>> Links:
>>>>> ------
>>>>> [1] http://www.smartools.com.co <http://www.smartools.com.co/>
>>>>>
>>>>
>>>
>
>
>
> Óscar Bou Bou
> Socio - IT & GRC Management Services Director
> m: +34 620 267 520 <tel:%2B34%20620%20267%20520>
> s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
>
> LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
> Twitter: @oscarbou <https://twitter.com/oscarbou>
>
>
>
> 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.
>
>
>
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
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.
Re: Edit modes in Apache Isis
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 25 May 2016 at 06:41, Óscar Bou - GOVERTIS <o....@govertis.com> wrote:
>
> @Dan
> 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).
Thx
Dan
> Regards,
>
> Oscar
>
>
>
>
> El 25 may 2016, a las 7:14, Dan Haywood <da...@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.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> frameworks.
>
> 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.
>
> Cheers
> Steve
>
>
>
>
>
> On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <dan@haywood-associates.co.uk
>
>
> wrote:
>
> Hi Hector,
> welcome to the users@ mailing list.
>
> I'm afraid that there isn't a setting to go back to the previous
>
> behaviour,
>
> 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
>
> a
>
> 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
>
> edit
>
> 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,
>
> but
>
> the number of clicks is actually the same.
>
> The philosophical reason is that, actually, it positions the framework
>
> away
>
> from the common perception of it being a CRUD framework; instead it is
>
> also
>
> 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
>
> (in
>
> stark contrast to the packaged application it replaced), not because
>
> there
>
> wasn't a requirement to allow the data to be changed, but instead he
>
> wanted
>
> 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,
>
> no
>
> 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
>
> position
>
> that action on a top-level panel. We do this for the contactapp [2].
>
> For
>
> your remaining more complex objects, I suggest that you sprinkle in some
> tabs, by way of recompense.
>
>
> Hope that helps
>
> Dan
>
> [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
>
> wrote:
>
>
>
> Hi,
>
> 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]
>
> Links:
> ------
> [1] http://www.smartools.com.co
>
>
>
>
>
> Óscar Bou Bou
> Socio - IT & GRC Management Services Director
> m: +34 620 267 520
> s: <http://www.govertis.com>www.govertis.com e: o.bou@govertis.com
>
> LinkedIn: https://www.linkedin.com/in/oscarbou
> Twitter: @oscarbou <https://twitter.com/oscarbou>
>
>
>
> 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.
>
>
Re: Edit modes in Apache Isis
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi all.
I think it’s also the correct way to do it.
A change in a property is considered at the UI the same way as an action execution “intent”, that can be successful or not, and can have logic associated with that update, including input validation.
@Dan
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.
Regards,
Oscar
> El 25 may 2016, a las 7:14, Dan Haywood <da...@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.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
>> frameworks.
>>
>> 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.
>>
>> Cheers
>> Steve
>>
>>
>>
>>
>>
>> On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <dan@haywood-associates.co.uk
>>>
>> wrote:
>>
>>> Hi Hector,
>>> welcome to the users@ mailing list.
>>>
>>> I'm afraid that there isn't a setting to go back to the previous
>> behaviour,
>>> 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
>> a
>>> 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
>> edit
>>> 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,
>> but
>>> the number of clicks is actually the same.
>>>
>>> The philosophical reason is that, actually, it positions the framework
>> away
>>> from the common perception of it being a CRUD framework; instead it is
>> also
>>> 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
>> (in
>>> stark contrast to the packaged application it replaced), not because
>> there
>>> wasn't a requirement to allow the data to be changed, but instead he
>> wanted
>>> 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,
>> no
>>> 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
>> position
>>> that action on a top-level panel. We do this for the contactapp [2].
>> For
>>> your remaining more complex objects, I suggest that you sprinkle in some
>>> tabs, by way of recompense.
>>>
>>>
>>> Hope that helps
>>>
>>> Dan
>>>
>>> [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
>>>
>>> wrote:
>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> 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]
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://www.smartools.com.co
>>>>
>>>
>>
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
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.
Re: Edit modes in Apache Isis
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Thanks for those thoughts, David; I'm happy with that analysis.
The Wicket viewer does support pluggable component views (cf the gmap3 and
fullcalendar2), so it would support the ability to render domain objects of
once "kind" (eg view models) differently than those of another (eg doman
entities). The same is probably true for editable tables, for bulk entry.
Anyway, expect to see something along these lines in a future version.
Thx
Dan
On 26 May 2016 at 01:07, Stephen Cameron <st...@gmail.com> wrote:
> Hi David,
>
> This is a very interesting, getting back to the first principles. The idea
> of a separate "tab through the fields type of thing" View Model to 'give
> birth' to an object does make good sense to me, it fills that purpose and
> that purpose only. The whole issue of 'edit mode' on a domain object and
> what that should mean disappears as, as you suggest, the default view of a
> domain object (in its nakedness) is largely behavioural.
>
> Thanks
>
> On Thu, May 26, 2016 at 7:02 AM, David Tildesley <
> davotnz@yahoo.co.nz.invalid> wrote:
>
> > Hi,
> > Just to add an architectural perspective - I think you are all right and
> > all wrong at the same time ;).
> > Dan is absolutely right if he constrains his comments to Domain Objects
> > (which I believe is the case).
> > I think the framework should enforce the Naked Object principles
> > (which are in turn are an expression of sound architecture and OO
> > principles and patterns) . And that means no CRUD exposed in the UI
> > directly from Domain Objects and for Domain Objects to be
> action/behaviour
> > oriented.
> > However in reference to the UI layer - then consider it disposable,
> > evolving and changing with new views as need for specific use cases. That
> > is precisely what the View Model is for in ISIS I believe.
> > The domain layer (domain objects), provided the domain model was well
> > designed in the first place, is mostly stable and easily extended over
> the
> > lifecycle of the application.
> > We can't stop developers from bleeding concerns across layers but we can
> > do more re-inforce the domain object/model and the rich domain pattern
> > which is a reflection of the principle of separation of concerns and
> > layering style.
> > What it does mean though, is that for many use cases, it is less likely
> > that you will expose the domain objects directly and more likely you will
> > use View Model (I hesitate to use the term View Object for obvious
> reasons)
> > and View Model will call behaviour on the domain objects as needed.
> > Which hopefully means that generated wicket UI/viewer behaviour from View
> > Model source will move to provide what some folk are asking for - a rapid
> > data input (tab through the fields type of thing). But not from domain
> > objects.
> > OK so it means that you need to deliberately layer your application by
> > separating View and Domain concerns ... but that is a good thing in the
> > long run of the life of your app is it not?
> > ISIS doesn't make the NO paradigm mandatory - that was caused by the
> > introduction of the view model - I think that is a good thing - provided
> > that you understand that the view model is UI layer only and you
> shouldn't
> > bleed domain behaviour into it.
> > Regards,David.
> >
> >
> >
> > On Thursday, 26 May 2016 5:15 AM, Dan Haywood <
> > dan@haywood-associates.co.uk> wrote:
> >
> >
> > Good input, thanks.
> >
> > My experience both with Estatio (4 years) but also with the big Naked
> > Objects system in Ireland (12 years) is that actions only is good enough
> in
> > the vast majority of cases ; and where bulk input is genuinely needed,
> then
> > we can usually address it with a little lateral thinking.
> >
> > For Estatio, there's an occasional requirement to bulk upload new tax
> > rates, and for that we use the isis-module-excel that allows the users to
> > just upload an excel spreadsheet and process that. Works quite well.
> >
> > The risk of allowing general free - form editing in ERP systems is that
> > users are liable to abuse the freedom... we saw this for example in the
> > packaged software that Estatio replaced... spare /unused fields end up
> > being co-opted to store all sorts of adhoc info. Instead, we should be
> > exploiting the fact that Isis allows such rapid development by keeping
> > things tight: relying on actions only means that the conversation as to
> > *why* the data needs to change can be had, resulting in a richer
> ubiquitous
> > language/insights/domain model.
> >
> > All that said, we'll continue to evolve and improve the default UI, and
> to
> > make it easier to allow it to be extended for use cases such as this. One
> > option is different UIs, or to use custom UIs based on the Restful
> viewer,
> > but they are completely different experiences from an end-user
> > perspective. Another more seamless/smoother integration might be to
> > leverage the nowicket framework which allows custom Wicket forms to be
> > developed quite easily; we've been in touch with its developer, and have
> > started spiking some things.
> >
> > Hope that helps explain some of the rationale a little better.
> >
> > Thanks,
> > Dan
> >
> > http://invesdwin.de/nowicket/introduction
> >
> > Hello. I have to agree with Steve and Hector. In my experience creating
> > and implementing ERP and large Merchandise Management systems, the
> > ability to change all fields within a TAB combined with in-line row
> > entry and editing is a must in a system where you handle a large volume
> > of transactional data entry (we have been extensively using those
> > features for the last 25 years or so in our systems, and the users
> > strongly request them). As an example use case, a user must enter
> > sometimes tens or even hundreds of rows (a purchase order line item
> > detail, a price change batch line item, journal entries and so on). Just
> > try doing that using the mouse and going back and forth on each row.
> > Luckily in our current applications we are building with Apache ISIS, we
> > are managing most of the data entry on the mobile devices, which handle
> > this in-line editing and all form editing easily, leveraging the amazing
> > ISIS capability to create web services from actions. But we do not see
> > us using the current Isis forms for that a system where there is volume
> > data entry in the browser. Having the ISIS ability to associate actions
> > to enter a group of fields / properties together and trigger some action
> > is beautiful, but I do not think it should replace all form editing nor
> > in-line row entry and editing, but they can both work as a complement.
> >
> > I've heard from Dan that ISIS will have additional viewer options in the
> > future as a result of its open hexagonal architecture and some join
> > efforts with the NakedObjects guys, which sounds great!. I hope they
> > might bring us some UI friendly features like those. I recognize there
> > have been some recent significant improvements to the UI configuration,
> > and hope there will be in-line row entry and editing and back to all
> > form / all TAB editing soon.
> >
> > Cesar.
> >
> > On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote:
> > > 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.
> > >
> > > Thx
> > > Dan
> > >
> > >
> > >
> > > On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> > > > frameworks.
> > > >
> > > > 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.
> > > >
> > > > Cheers
> > > > Steve
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <
> > dan@haywood-associates.co.uk
> > > > >
> > > > wrote:
> > > >
> > > > > Hi Hector,
> > > > > welcome to the users@ mailing list.
> > > > >
> > > > > I'm afraid that there isn't a setting to go back to the previous
> > > > behaviour,
> > > > > 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
> > > > a
> > > > > 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
> > > > edit
> > > > > 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,
> > > > but
> > > > > the number of clicks is actually the same.
> > > > >
> > > > > The philosophical reason is that, actually, it positions the
> > framework
> > > > away
> > > > > from the common perception of it being a CRUD framework; instead it
> > is
> > > > also
> > > > > 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
> > > > (in
> > > > > stark contrast to the packaged application it replaced), not
> because
> > > > there
> > > > > wasn't a requirement to allow the data to be changed, but instead
> he
> > > > wanted
> > > > > 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,
> > > > no
> > > > > 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
> > > > position
> > > > > that action on a top-level panel. We do this for the contactapp
> [2].
> > > > For
> > > > > your remaining more complex objects, I suggest that you sprinkle in
> > some
> > > > > tabs, by way of recompense.
> > > > >
> > > > >
> > > > > Hope that helps
> > > > >
> > > > > Dan
> > > > >
> > > > > [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
> > > > >
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > 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]
> > > > > >
> > > > > > Links:
> > > > > > ------
> > > > > > [1] http://www.smartools.com.co/
> > > > > >
> > > > >
> > > >
> >
> >
>
Re: Edit modes in Apache Isis
Posted by Stephen Cameron <st...@gmail.com>.
Hi David,
This is a very interesting, getting back to the first principles. The idea
of a separate "tab through the fields type of thing" View Model to 'give
birth' to an object does make good sense to me, it fills that purpose and
that purpose only. The whole issue of 'edit mode' on a domain object and
what that should mean disappears as, as you suggest, the default view of a
domain object (in its nakedness) is largely behavioural.
Thanks
On Thu, May 26, 2016 at 7:02 AM, David Tildesley <
davotnz@yahoo.co.nz.invalid> wrote:
> Hi,
> Just to add an architectural perspective - I think you are all right and
> all wrong at the same time ;).
> Dan is absolutely right if he constrains his comments to Domain Objects
> (which I believe is the case).
> I think the framework should enforce the Naked Object principles
> (which are in turn are an expression of sound architecture and OO
> principles and patterns) . And that means no CRUD exposed in the UI
> directly from Domain Objects and for Domain Objects to be action/behaviour
> oriented.
> However in reference to the UI layer - then consider it disposable,
> evolving and changing with new views as need for specific use cases. That
> is precisely what the View Model is for in ISIS I believe.
> The domain layer (domain objects), provided the domain model was well
> designed in the first place, is mostly stable and easily extended over the
> lifecycle of the application.
> We can't stop developers from bleeding concerns across layers but we can
> do more re-inforce the domain object/model and the rich domain pattern
> which is a reflection of the principle of separation of concerns and
> layering style.
> What it does mean though, is that for many use cases, it is less likely
> that you will expose the domain objects directly and more likely you will
> use View Model (I hesitate to use the term View Object for obvious reasons)
> and View Model will call behaviour on the domain objects as needed.
> Which hopefully means that generated wicket UI/viewer behaviour from View
> Model source will move to provide what some folk are asking for - a rapid
> data input (tab through the fields type of thing). But not from domain
> objects.
> OK so it means that you need to deliberately layer your application by
> separating View and Domain concerns ... but that is a good thing in the
> long run of the life of your app is it not?
> ISIS doesn't make the NO paradigm mandatory - that was caused by the
> introduction of the view model - I think that is a good thing - provided
> that you understand that the view model is UI layer only and you shouldn't
> bleed domain behaviour into it.
> Regards,David.
>
>
>
> On Thursday, 26 May 2016 5:15 AM, Dan Haywood <
> dan@haywood-associates.co.uk> wrote:
>
>
> Good input, thanks.
>
> My experience both with Estatio (4 years) but also with the big Naked
> Objects system in Ireland (12 years) is that actions only is good enough in
> the vast majority of cases ; and where bulk input is genuinely needed, then
> we can usually address it with a little lateral thinking.
>
> For Estatio, there's an occasional requirement to bulk upload new tax
> rates, and for that we use the isis-module-excel that allows the users to
> just upload an excel spreadsheet and process that. Works quite well.
>
> The risk of allowing general free - form editing in ERP systems is that
> users are liable to abuse the freedom... we saw this for example in the
> packaged software that Estatio replaced... spare /unused fields end up
> being co-opted to store all sorts of adhoc info. Instead, we should be
> exploiting the fact that Isis allows such rapid development by keeping
> things tight: relying on actions only means that the conversation as to
> *why* the data needs to change can be had, resulting in a richer ubiquitous
> language/insights/domain model.
>
> All that said, we'll continue to evolve and improve the default UI, and to
> make it easier to allow it to be extended for use cases such as this. One
> option is different UIs, or to use custom UIs based on the Restful viewer,
> but they are completely different experiences from an end-user
> perspective. Another more seamless/smoother integration might be to
> leverage the nowicket framework which allows custom Wicket forms to be
> developed quite easily; we've been in touch with its developer, and have
> started spiking some things.
>
> Hope that helps explain some of the rationale a little better.
>
> Thanks,
> Dan
>
> http://invesdwin.de/nowicket/introduction
>
> Hello. I have to agree with Steve and Hector. In my experience creating
> and implementing ERP and large Merchandise Management systems, the
> ability to change all fields within a TAB combined with in-line row
> entry and editing is a must in a system where you handle a large volume
> of transactional data entry (we have been extensively using those
> features for the last 25 years or so in our systems, and the users
> strongly request them). As an example use case, a user must enter
> sometimes tens or even hundreds of rows (a purchase order line item
> detail, a price change batch line item, journal entries and so on). Just
> try doing that using the mouse and going back and forth on each row.
> Luckily in our current applications we are building with Apache ISIS, we
> are managing most of the data entry on the mobile devices, which handle
> this in-line editing and all form editing easily, leveraging the amazing
> ISIS capability to create web services from actions. But we do not see
> us using the current Isis forms for that a system where there is volume
> data entry in the browser. Having the ISIS ability to associate actions
> to enter a group of fields / properties together and trigger some action
> is beautiful, but I do not think it should replace all form editing nor
> in-line row entry and editing, but they can both work as a complement.
>
> I've heard from Dan that ISIS will have additional viewer options in the
> future as a result of its open hexagonal architecture and some join
> efforts with the NakedObjects guys, which sounds great!. I hope they
> might bring us some UI friendly features like those. I recognize there
> have been some recent significant improvements to the UI configuration,
> and hope there will be in-line row entry and editing and back to all
> form / all TAB editing soon.
>
> Cesar.
>
> On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote:
> > 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.
> >
> > Thx
> > Dan
> >
> >
> >
> > On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> > > frameworks.
> > >
> > > 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.
> > >
> > > Cheers
> > > Steve
> > >
> > >
> > >
> > >
> > >
> > > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <
> dan@haywood-associates.co.uk
> > > >
> > > wrote:
> > >
> > > > Hi Hector,
> > > > welcome to the users@ mailing list.
> > > >
> > > > I'm afraid that there isn't a setting to go back to the previous
> > > behaviour,
> > > > 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
> > > a
> > > > 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
> > > edit
> > > > 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,
> > > but
> > > > the number of clicks is actually the same.
> > > >
> > > > The philosophical reason is that, actually, it positions the
> framework
> > > away
> > > > from the common perception of it being a CRUD framework; instead it
> is
> > > also
> > > > 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
> > > (in
> > > > stark contrast to the packaged application it replaced), not because
> > > there
> > > > wasn't a requirement to allow the data to be changed, but instead he
> > > wanted
> > > > 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,
> > > no
> > > > 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
> > > position
> > > > that action on a top-level panel. We do this for the contactapp [2].
> > > For
> > > > your remaining more complex objects, I suggest that you sprinkle in
> some
> > > > tabs, by way of recompense.
> > > >
> > > >
> > > > Hope that helps
> > > >
> > > > Dan
> > > >
> > > > [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
> > > >
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > 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]
> > > > >
> > > > > Links:
> > > > > ------
> > > > > [1] http://www.smartools.com.co/
> > > > >
> > > >
> > >
>
>
Re: Edit modes in Apache Isis
Posted by David Tildesley <da...@yahoo.co.nz.INVALID>.
Hi,
Just to add an architectural perspective - I think you are all right and all wrong at the same time ;).
Dan is absolutely right if he constrains his comments to Domain Objects (which I believe is the case).
I think the framework should enforce the Naked Object principles (which are in turn are an expression of sound architecture and OO principles and patterns) . And that means no CRUD exposed in the UI directly from Domain Objects and for Domain Objects to be action/behaviour oriented.
However in reference to the UI layer - then consider it disposable, evolving and changing with new views as need for specific use cases. That is precisely what the View Model is for in ISIS I believe.
The domain layer (domain objects), provided the domain model was well designed in the first place, is mostly stable and easily extended over the lifecycle of the application.
We can't stop developers from bleeding concerns across layers but we can do more re-inforce the domain object/model and the rich domain pattern which is a reflection of the principle of separation of concerns and layering style.
What it does mean though, is that for many use cases, it is less likely that you will expose the domain objects directly and more likely you will use View Model (I hesitate to use the term View Object for obvious reasons) and View Model will call behaviour on the domain objects as needed.
Which hopefully means that generated wicket UI/viewer behaviour from View Model source will move to provide what some folk are asking for - a rapid data input (tab through the fields type of thing). But not from domain objects.
OK so it means that you need to deliberately layer your application by separating View and Domain concerns ... but that is a good thing in the long run of the life of your app is it not?
ISIS doesn't make the NO paradigm mandatory - that was caused by the introduction of the view model - I think that is a good thing - provided that you understand that the view model is UI layer only and you shouldn't bleed domain behaviour into it.
Regards,David.
On Thursday, 26 May 2016 5:15 AM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
Good input, thanks.
My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.
For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that. Works quite well.
The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info. Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.
All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective. Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.
Hope that helps explain some of the rationale a little better.
Thanks,
Dan
http://invesdwin.de/nowicket/introduction
Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.
I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.
Cesar.
On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote:
> 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.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> > frameworks.
> >
> > 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.
> >
> > Cheers
> > Steve
> >
> >
> >
> >
> >
> > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <
dan@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > Hi Hector,
> > > welcome to the users@ mailing list.
> > >
> > > I'm afraid that there isn't a setting to go back to the previous
> > behaviour,
> > > 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
> > a
> > > 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
> > edit
> > > 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,
> > but
> > > the number of clicks is actually the same.
> > >
> > > The philosophical reason is that, actually, it positions the framework
> > away
> > > from the common perception of it being a CRUD framework; instead it is
> > also
> > > 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
> > (in
> > > stark contrast to the packaged application it replaced), not because
> > there
> > > wasn't a requirement to allow the data to be changed, but instead he
> > wanted
> > > 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,
> > no
> > > 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
> > position
> > > that action on a top-level panel. We do this for the contactapp [2].
> > For
> > > your remaining more complex objects, I suggest that you sprinkle in
some
> > > tabs, by way of recompense.
> > >
> > >
> > > Hope that helps
> > >
> > > Dan
> > >
> > > [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
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > 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]
> > > >
> > > > Links:
> > > > ------
> > > > [1] http://www.smartools.com.co/
> > > >
> > >
> >
Re: Edit modes in Apache Isis
Posted by César Camilo Lugo Marcos <ce...@sisorg.com.mx>.
Dan,
After a quick look, I can see why you are considering nowicket. I particularly like these features:
- DDD and NO incorporated too. In line with ISIS.
- Keep the automatic generation of forms from model ISIS concept.
- You customize forms by using HTML, instead of a domain specific language or markup language, even using a WYSIWYG editor. If rebuilding a form, you don't loose the changes you made to it, changes are merged.
- You can use anything Wicket supports (that includes mutable in-line editing. I saw a couple of examples in the Wicket Examples Rebuilt" section, Ajax Datatable and Form Input).
- I guess in the ISIS integration you might be able to maintain the ability to group actions with properties editing in those cases where it makes sense.
Sounds promising.
Cesar.
On Wed, 2016-05-25 at 18:15 +0100, Dan Haywood
Good input, thanks.
My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.
For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that. Works quite well.
The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info. Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.
All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective. Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.
Hope that helps explain some of the rationale a little better.
Thanks,
Dan
http://invesdwin.de/nowicket/introduction
Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.
I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.
Cesar.
On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote:
> 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.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> > frameworks.
> >
> > 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.
> >
> > Cheers
> > Steve
> >
> >
> >
> >
> >
> > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>
> > >
> > wrote:
> >
> > > Hi Hector,
> > > welcome to the users@ mailing list.
> > >
> > > I'm afraid that there isn't a setting to go back to the previous
> > behaviour,
> > > 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
> > a
> > > 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
> > edit
> > > 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,
> > but
> > > the number of clicks is actually the same.
> > >
> > > The philosophical reason is that, actually, it positions the framework
> > away
> > > from the common perception of it being a CRUD framework; instead it is
> > also
> > > 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
> > (in
> > > stark contrast to the packaged application it replaced), not because
> > there
> > > wasn't a requirement to allow the data to be changed, but instead he
> > wanted
> > > 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,
> > no
> > > 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
> > position
> > > that action on a top-level panel. We do this for the contactapp [2].
> > For
> > > your remaining more complex objects, I suggest that you sprinkle in
some
> > > tabs, by way of recompense.
> > >
> > >
> > > Hope that helps
> > >
> > > Dan
> > >
> > > [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<ma...@smartools.com.co>
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > 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<http://www.smartools.com.co> [1]
> > > >
> > > > Links:
> > > > ------
> > > > [1] http://www.smartools.com.co
> > > >
> > >
> >
Re: Edit modes in Apache Isis
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Good input, thanks.
My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.
For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that. Works quite well.
The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info. Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.
All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective. Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.
Hope that helps explain some of the rationale a little better.
Thanks,
Dan
http://invesdwin.de/nowicket/introduction
Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.
I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.
Cesar.
On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote:
> 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.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> > frameworks.
> >
> > 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.
> >
> > Cheers
> > Steve
> >
> >
> >
> >
> >
> > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <
dan@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > Hi Hector,
> > > welcome to the users@ mailing list.
> > >
> > > I'm afraid that there isn't a setting to go back to the previous
> > behaviour,
> > > 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
> > a
> > > 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
> > edit
> > > 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,
> > but
> > > the number of clicks is actually the same.
> > >
> > > The philosophical reason is that, actually, it positions the framework
> > away
> > > from the common perception of it being a CRUD framework; instead it is
> > also
> > > 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
> > (in
> > > stark contrast to the packaged application it replaced), not because
> > there
> > > wasn't a requirement to allow the data to be changed, but instead he
> > wanted
> > > 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,
> > no
> > > 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
> > position
> > > that action on a top-level panel. We do this for the contactapp [2].
> > For
> > > your remaining more complex objects, I suggest that you sprinkle in
some
> > > tabs, by way of recompense.
> > >
> > >
> > > Hope that helps
> > >
> > > Dan
> > >
> > > [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
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > 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]
> > > >
> > > > Links:
> > > > ------
> > > > [1] http://www.smartools.com.co
> > > >
> > >
> >
Re: Edit modes in Apache Isis
Posted by César Camilo Lugo Marcos <ce...@sisorg.com.mx>.
Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.
I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.
Cesar.
On Wed, 2016-05-25 at 05:14 +0000, Dan Haywood wrote:
> 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.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> > frameworks.
> >
> > 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.
> >
> > Cheers
> > Steve
> >
> >
> >
> >
> >
> > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <dan@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > Hi Hector,
> > > welcome to the users@ mailing list.
> > >
> > > I'm afraid that there isn't a setting to go back to the previous
> > behaviour,
> > > 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
> > a
> > > 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
> > edit
> > > 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,
> > but
> > > the number of clicks is actually the same.
> > >
> > > The philosophical reason is that, actually, it positions the framework
> > away
> > > from the common perception of it being a CRUD framework; instead it is
> > also
> > > 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
> > (in
> > > stark contrast to the packaged application it replaced), not because
> > there
> > > wasn't a requirement to allow the data to be changed, but instead he
> > wanted
> > > 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,
> > no
> > > 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
> > position
> > > that action on a top-level panel. We do this for the contactapp [2].
> > For
> > > your remaining more complex objects, I suggest that you sprinkle in some
> > > tabs, by way of recompense.
> > >
> > >
> > > Hope that helps
> > >
> > > Dan
> > >
> > > [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
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > 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]
> > > >
> > > > Links:
> > > > ------
> > > > [1] http://www.smartools.com.co
> > > >
> > >
> >
Re: Edit modes in Apache Isis
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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.
Thx
Dan
On 25 May 2016 at 03:36, Stephen Cameron <st...@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'
> frameworks.
>
> 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.
>
> Cheers
> Steve
>
>
>
>
>
> On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <dan@haywood-associates.co.uk
> >
> wrote:
>
> > Hi Hector,
> > welcome to the users@ mailing list.
> >
> > I'm afraid that there isn't a setting to go back to the previous
> behaviour,
> > 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
> a
> > 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
> edit
> > 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,
> but
> > the number of clicks is actually the same.
> >
> > The philosophical reason is that, actually, it positions the framework
> away
> > from the common perception of it being a CRUD framework; instead it is
> also
> > 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
> (in
> > stark contrast to the packaged application it replaced), not because
> there
> > wasn't a requirement to allow the data to be changed, but instead he
> wanted
> > 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,
> no
> > 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
> position
> > that action on a top-level panel. We do this for the contactapp [2].
> For
> > your remaining more complex objects, I suggest that you sprinkle in some
> > tabs, by way of recompense.
> >
> >
> > Hope that helps
> >
> > Dan
> >
> > [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
> >
> > wrote:
> >
> > >
> > >
> > > Hi,
> > >
> > > 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]
> > >
> > > Links:
> > > ------
> > > [1] http://www.smartools.com.co
> > >
> >
>
Re: Edit modes in Apache Isis
Posted by Stephen Cameron <st...@gmail.com>.
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'
frameworks.
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.
Cheers
Steve
On Tue, May 24, 2016 at 4:00 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi Hector,
> welcome to the users@ mailing list.
>
> I'm afraid that there isn't a setting to go back to the previous behaviour,
> 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 a
> 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 edit
> 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, but
> the number of clicks is actually the same.
>
> The philosophical reason is that, actually, it positions the framework away
> from the common perception of it being a CRUD framework; instead it is also
> 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 (in
> stark contrast to the packaged application it replaced), not because there
> wasn't a requirement to allow the data to be changed, but instead he wanted
> 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, no
> 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 position
> that action on a top-level panel. We do this for the contactapp [2]. For
> your remaining more complex objects, I suggest that you sprinkle in some
> tabs, by way of recompense.
>
>
> Hope that helps
>
> Dan
>
> [1] http://github.com/estatio/estatio
> [2] http://github.com/incodehq/contactapp
>
>
>
> On 23 May 2016 at 21:13, Hector Fabio Meza <he...@smartools.com.co>
> wrote:
>
> >
> >
> > Hi,
> >
> > 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]
> >
> > Links:
> > ------
> > [1] http://www.smartools.com.co
> >
>
Re: Edit modes in Apache Isis
Posted by Dan Haywood <da...@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 behaviour,
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 a
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 edit
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, but
the number of clicks is actually the same.
The philosophical reason is that, actually, it positions the framework away
from the common perception of it being a CRUD framework; instead it is also
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 (in
stark contrast to the packaged application it replaced), not because there
wasn't a requirement to allow the data to be changed, but instead he wanted
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, no
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 position
that action on a top-level panel. We do this for the contactapp [2]. For
your remaining more complex objects, I suggest that you sprinkle in some
tabs, by way of recompense.
Hope that helps
Dan
[1] http://github.com/estatio/estatio
[2] http://github.com/incodehq/contactapp
On 23 May 2016 at 21:13, Hector Fabio Meza <he...@smartools.com.co>
wrote:
>
>
> Hi,
>
> 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]
>
> Links:
> ------
> [1] http://www.smartools.com.co
>