isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: Edit modes in Apache Isis
Date Wed, 25 May 2016 05:14:54 GMT
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> 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message