You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Stephen Cameron <st...@gmail.com> on 2016/04/20 04:00:56 UTC
1.12 changes to editing
Hi,
I want to give a little feed-back on the addition of the edit button to the
bottom right of each editable control. I note that this is probably a
temporary thing but I'm not very keen on it so encourage a change to be
made.
My problems with it are that its pushes the next control down the page and
wastes space, and it means more actions if you are editing more than one
item.
One solution is to make all controls non-editable and provide a mass-update
action inside each group, this seems common in Estatio, but I don't see it
as a good practice get into, unless common workflows suggest it, there is a
far bit of work to do it and it seems to take you away from the Naked
Objects paradigm.
The question is what is the best solution?
Personally I thought the global Edit (mode) button was fine, its pretty
standard. But placing it in the left column under all the groups did have
the undesirable effect of pushing it down out of sight sometimes. With tabs
that is not a good solution either, i.e on the first tab, and putting it
under the tab-panel not any better.
One solution is to put it into the first 'title' row of the page, but
aligned on the right-hand side to differentiate is from other actions that
might be there, its kind of an action button.
Having tabs is very welcome though, so now I have a dilemma. Go to 1.12 or
wait to see if the edit buttons disappear in 1.13. I am inclined to stay at
1.11.
Of course, as mentioned, there were issues associated with making JAXB view
models editable. If this has led to too much complexity in the viewer then
maybe it wasn't such a good move? My concern with that aspect has been that
conflating JAXB and a View-model mode.
I hope this is of some usefulness.
Regards
Steve Cameron
Re: 1.12 changes to editing
Posted by Stephen Cameron <st...@gmail.com>.
thanks
On Thu, Apr 21, 2016 at 4:47 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> within...
>
>
> On 20 April 2016 at 10:08, Stephen Cameron <st...@gmail.com>
> wrote:
>
> >
> > The one major concern I have is simply the efficient manual entry of
> large
> > amounts of data, maybe from a paper format, so being able to enter data
> by
> > tabbing without using the mouse is still desired by some. Maybe there
> is a
> > the need for another kind of viewer for this scenario?
> >
> >
> For this, we use isis-module-excel. This allows the upload of an Excel
> spreadsheet, which is then processed server-side. We use it for the bulk
> upload of new tax tables once a year.
>
>
>
> > This conversation has been had before, with the workflow add-on suggested
> > as a possible solution. But there is also the scenario of needing a
> > printable form. I'd like to be able to maintain one version of a such a
> > printable 'form' only, that is to design something that can be printed
> and
> > handed to be people for filling out, but which in its electronic form can
> > be used for easy data-entry straight into the database.
> >
> >
> Well, we have isis-module-docx which can be used. I'm a fan of using Word
> as the template language; isis-module-docx is actually a port from the
> equivalent .NET implementation that I wrote for the big naked objects
> system over in Ireland. We've had several implementations of generating
> comms over the years, but isis-module-docx equivalent has been the easiest
> to work with.
>
> That said, for Estatio we actually just use SQL Server reporting, I
> believe. Jeroen has also played with xdocreport [1] which also looks
> promising.
>
>
>
>
>
> > I've considered using Orbeon Forms (an XForms framework) in concert with
> > Apache Isis as the solution to this issue. With JAXB support now in Isis
> it
> > does seem like a nice combo, XML from the XForm into Apache Isis (and
> > database) via JAXB.
> >
> >
> Maybe... but our first comms implementation over in Ireland was something
> similar, using Altova Stylevision along with XML and XSD generated from the
> domain model (we used the xmlsnapshotservice). Bottom line is that it was
> quite labour intensive to work with.
>
>
>
>
> > >
> > > This is where I am departing in that what I have is essentially a CRUD
> > app. Such an app with multiple viewers, all easy to maintain, and with
> the
> > capacity for adding complexity where necessary (via actions, different
> > user authorisations) is still a very good thing to have.
> >
> >
> You could knock together have a dedicated Javascript app hitting our REST
> API, then provide an action returning a URL to "launch" that viewer as a
> different tab.
>
>
>
>
> >
> >
> > I kind of see your point, but maybe it would be nice to make this
> > configurable, that is non-edit is default and you add actions to change
> > state, or, edit as default and no actions needed? (the later to please us
> > crudites, its a web-form mode I feel).
> >
> >
> Actually, this is already configurable. I've left the simpleapp archetype
> to have edit mode as default, but this could change in the future.
>
> At any rate, use isis.objects.editing [2]
>
>
>
> >
> > Just moving the edit icon to the right as a short-term option would be
> > good.
> >
> >
>
> I played around with this a bit; the following CSS (in application.css)
> moves the existing edit icon overload onto the entry field itself, which I
> think looks rather nice:
>
> div.stringPanel span.editing a.edit {
> margin-top: -20px;
> margin-bottom: 0px;
> margin-right: 5px;
> }
>
> This applies to only string fields; you could adapt for other field types
> by cloning the CSS line for other containing panels ("div.stringPanel...")
>
> HTH
> Dan
>
>
> [1] https://github.com/opensagres/xdocreport
> [2]
>
> http://isis.apache.org/guides/rgcfg.html#_rgcfg_configuring-core_isis-objects-editing
>
Re: 1.12 changes to editing
Posted by Stephen Cameron <st...@gmail.com>.
No luck, not sure why, but I am happy with what I have.
On Thu, Apr 21, 2016 at 9:36 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Was clickable on chrome/windows, but didn't test it anywhere else. Another
> option that might ensure it definitely being clickable would be to set
> z-index [1]
>
>
> [1] https://developer.mozilla.org/en/docs/Web/CSS/z-index
>
> On 21 April 2016 at 12:33, Stephen Cameron <st...@gmail.com>
> wrote:
>
> > re css for moving edit icon
> >
> > moving it up and right too makes it not so nice but clickable :)
> >
> > div.stringPanel span.editing a.edit {
> > margin-top: -20px;
> > margin-bottom: 0px;
> > margin-right: -20px;
> > }
> >
> > thanks for the tip
> >
> > On Thu, Apr 21, 2016 at 4:47 PM, Dan Haywood <
> dan@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > within...
> > >
> > >
> > > On 20 April 2016 at 10:08, Stephen Cameron <steve.cameron.62@gmail.com
> >
> > > wrote:
> > >
> > > >
> > > > The one major concern I have is simply the efficient manual entry of
> > > large
> > > > amounts of data, maybe from a paper format, so being able to enter
> data
> > > by
> > > > tabbing without using the mouse is still desired by some. Maybe
> there
> > > is a
> > > > the need for another kind of viewer for this scenario?
> > > >
> > > >
> > > For this, we use isis-module-excel. This allows the upload of an Excel
> > > spreadsheet, which is then processed server-side. We use it for the
> bulk
> > > upload of new tax tables once a year.
> > >
> > >
> > >
> > > > This conversation has been had before, with the workflow add-on
> > suggested
> > > > as a possible solution. But there is also the scenario of needing a
> > > > printable form. I'd like to be able to maintain one version of a
> such a
> > > > printable 'form' only, that is to design something that can be
> printed
> > > and
> > > > handed to be people for filling out, but which in its electronic form
> > can
> > > > be used for easy data-entry straight into the database.
> > > >
> > > >
> > > Well, we have isis-module-docx which can be used. I'm a fan of using
> > Word
> > > as the template language; isis-module-docx is actually a port from the
> > > equivalent .NET implementation that I wrote for the big naked objects
> > > system over in Ireland. We've had several implementations of
> generating
> > > comms over the years, but isis-module-docx equivalent has been the
> > easiest
> > > to work with.
> > >
> > > That said, for Estatio we actually just use SQL Server reporting, I
> > > believe. Jeroen has also played with xdocreport [1] which also looks
> > > promising.
> > >
> > >
> > >
> > >
> > >
> > > > I've considered using Orbeon Forms (an XForms framework) in concert
> > with
> > > > Apache Isis as the solution to this issue. With JAXB support now in
> > Isis
> > > it
> > > > does seem like a nice combo, XML from the XForm into Apache Isis (and
> > > > database) via JAXB.
> > > >
> > > >
> > > Maybe... but our first comms implementation over in Ireland was
> something
> > > similar, using Altova Stylevision along with XML and XSD generated from
> > the
> > > domain model (we used the xmlsnapshotservice). Bottom line is that it
> > was
> > > quite labour intensive to work with.
> > >
> > >
> > >
> > >
> > > > >
> > > > > This is where I am departing in that what I have is essentially a
> > CRUD
> > > > app. Such an app with multiple viewers, all easy to maintain, and
> with
> > > the
> > > > capacity for adding complexity where necessary (via actions,
> different
> > > > user authorisations) is still a very good thing to have.
> > > >
> > > >
> > > You could knock together have a dedicated Javascript app hitting our
> REST
> > > API, then provide an action returning a URL to "launch" that viewer as
> a
> > > different tab.
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > I kind of see your point, but maybe it would be nice to make this
> > > > configurable, that is non-edit is default and you add actions to
> change
> > > > state, or, edit as default and no actions needed? (the later to
> please
> > us
> > > > crudites, its a web-form mode I feel).
> > > >
> > > >
> > > Actually, this is already configurable. I've left the simpleapp
> > archetype
> > > to have edit mode as default, but this could change in the future.
> > >
> > > At any rate, use isis.objects.editing [2]
> > >
> > >
> > >
> > > >
> > > > Just moving the edit icon to the right as a short-term option would
> be
> > > > good.
> > > >
> > > >
> > >
> > > I played around with this a bit; the following CSS (in application.css)
> > > moves the existing edit icon overload onto the entry field itself,
> which
> > I
> > > think looks rather nice:
> > >
> > > div.stringPanel span.editing a.edit {
> > > margin-top: -20px;
> > > margin-bottom: 0px;
> > > margin-right: 5px;
> > > }
> > >
> > > This applies to only string fields; you could adapt for other field
> types
> > > by cloning the CSS line for other containing panels
> > ("div.stringPanel...")
> > >
> > > HTH
> > > Dan
> > >
> > >
> > > [1] https://github.com/opensagres/xdocreport
> > > [2]
> > >
> > >
> >
> http://isis.apache.org/guides/rgcfg.html#_rgcfg_configuring-core_isis-objects-editing
> > >
> >
>
Re: 1.12 changes to editing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Was clickable on chrome/windows, but didn't test it anywhere else. Another
option that might ensure it definitely being clickable would be to set
z-index [1]
[1] https://developer.mozilla.org/en/docs/Web/CSS/z-index
On 21 April 2016 at 12:33, Stephen Cameron <st...@gmail.com>
wrote:
> re css for moving edit icon
>
> moving it up and right too makes it not so nice but clickable :)
>
> div.stringPanel span.editing a.edit {
> margin-top: -20px;
> margin-bottom: 0px;
> margin-right: -20px;
> }
>
> thanks for the tip
>
> On Thu, Apr 21, 2016 at 4:47 PM, Dan Haywood <dan@haywood-associates.co.uk
> >
> wrote:
>
> > within...
> >
> >
> > On 20 April 2016 at 10:08, Stephen Cameron <st...@gmail.com>
> > wrote:
> >
> > >
> > > The one major concern I have is simply the efficient manual entry of
> > large
> > > amounts of data, maybe from a paper format, so being able to enter data
> > by
> > > tabbing without using the mouse is still desired by some. Maybe there
> > is a
> > > the need for another kind of viewer for this scenario?
> > >
> > >
> > For this, we use isis-module-excel. This allows the upload of an Excel
> > spreadsheet, which is then processed server-side. We use it for the bulk
> > upload of new tax tables once a year.
> >
> >
> >
> > > This conversation has been had before, with the workflow add-on
> suggested
> > > as a possible solution. But there is also the scenario of needing a
> > > printable form. I'd like to be able to maintain one version of a such a
> > > printable 'form' only, that is to design something that can be printed
> > and
> > > handed to be people for filling out, but which in its electronic form
> can
> > > be used for easy data-entry straight into the database.
> > >
> > >
> > Well, we have isis-module-docx which can be used. I'm a fan of using
> Word
> > as the template language; isis-module-docx is actually a port from the
> > equivalent .NET implementation that I wrote for the big naked objects
> > system over in Ireland. We've had several implementations of generating
> > comms over the years, but isis-module-docx equivalent has been the
> easiest
> > to work with.
> >
> > That said, for Estatio we actually just use SQL Server reporting, I
> > believe. Jeroen has also played with xdocreport [1] which also looks
> > promising.
> >
> >
> >
> >
> >
> > > I've considered using Orbeon Forms (an XForms framework) in concert
> with
> > > Apache Isis as the solution to this issue. With JAXB support now in
> Isis
> > it
> > > does seem like a nice combo, XML from the XForm into Apache Isis (and
> > > database) via JAXB.
> > >
> > >
> > Maybe... but our first comms implementation over in Ireland was something
> > similar, using Altova Stylevision along with XML and XSD generated from
> the
> > domain model (we used the xmlsnapshotservice). Bottom line is that it
> was
> > quite labour intensive to work with.
> >
> >
> >
> >
> > > >
> > > > This is where I am departing in that what I have is essentially a
> CRUD
> > > app. Such an app with multiple viewers, all easy to maintain, and with
> > the
> > > capacity for adding complexity where necessary (via actions, different
> > > user authorisations) is still a very good thing to have.
> > >
> > >
> > You could knock together have a dedicated Javascript app hitting our REST
> > API, then provide an action returning a URL to "launch" that viewer as a
> > different tab.
> >
> >
> >
> >
> > >
> > >
> > > I kind of see your point, but maybe it would be nice to make this
> > > configurable, that is non-edit is default and you add actions to change
> > > state, or, edit as default and no actions needed? (the later to please
> us
> > > crudites, its a web-form mode I feel).
> > >
> > >
> > Actually, this is already configurable. I've left the simpleapp
> archetype
> > to have edit mode as default, but this could change in the future.
> >
> > At any rate, use isis.objects.editing [2]
> >
> >
> >
> > >
> > > Just moving the edit icon to the right as a short-term option would be
> > > good.
> > >
> > >
> >
> > I played around with this a bit; the following CSS (in application.css)
> > moves the existing edit icon overload onto the entry field itself, which
> I
> > think looks rather nice:
> >
> > div.stringPanel span.editing a.edit {
> > margin-top: -20px;
> > margin-bottom: 0px;
> > margin-right: 5px;
> > }
> >
> > This applies to only string fields; you could adapt for other field types
> > by cloning the CSS line for other containing panels
> ("div.stringPanel...")
> >
> > HTH
> > Dan
> >
> >
> > [1] https://github.com/opensagres/xdocreport
> > [2]
> >
> >
> http://isis.apache.org/guides/rgcfg.html#_rgcfg_configuring-core_isis-objects-editing
> >
>
Re: 1.12 changes to editing
Posted by Stephen Cameron <st...@gmail.com>.
re css for moving edit icon
moving it up and right too makes it not so nice but clickable :)
div.stringPanel span.editing a.edit {
margin-top: -20px;
margin-bottom: 0px;
margin-right: -20px;
}
thanks for the tip
On Thu, Apr 21, 2016 at 4:47 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> within...
>
>
> On 20 April 2016 at 10:08, Stephen Cameron <st...@gmail.com>
> wrote:
>
> >
> > The one major concern I have is simply the efficient manual entry of
> large
> > amounts of data, maybe from a paper format, so being able to enter data
> by
> > tabbing without using the mouse is still desired by some. Maybe there
> is a
> > the need for another kind of viewer for this scenario?
> >
> >
> For this, we use isis-module-excel. This allows the upload of an Excel
> spreadsheet, which is then processed server-side. We use it for the bulk
> upload of new tax tables once a year.
>
>
>
> > This conversation has been had before, with the workflow add-on suggested
> > as a possible solution. But there is also the scenario of needing a
> > printable form. I'd like to be able to maintain one version of a such a
> > printable 'form' only, that is to design something that can be printed
> and
> > handed to be people for filling out, but which in its electronic form can
> > be used for easy data-entry straight into the database.
> >
> >
> Well, we have isis-module-docx which can be used. I'm a fan of using Word
> as the template language; isis-module-docx is actually a port from the
> equivalent .NET implementation that I wrote for the big naked objects
> system over in Ireland. We've had several implementations of generating
> comms over the years, but isis-module-docx equivalent has been the easiest
> to work with.
>
> That said, for Estatio we actually just use SQL Server reporting, I
> believe. Jeroen has also played with xdocreport [1] which also looks
> promising.
>
>
>
>
>
> > I've considered using Orbeon Forms (an XForms framework) in concert with
> > Apache Isis as the solution to this issue. With JAXB support now in Isis
> it
> > does seem like a nice combo, XML from the XForm into Apache Isis (and
> > database) via JAXB.
> >
> >
> Maybe... but our first comms implementation over in Ireland was something
> similar, using Altova Stylevision along with XML and XSD generated from the
> domain model (we used the xmlsnapshotservice). Bottom line is that it was
> quite labour intensive to work with.
>
>
>
>
> > >
> > > This is where I am departing in that what I have is essentially a CRUD
> > app. Such an app with multiple viewers, all easy to maintain, and with
> the
> > capacity for adding complexity where necessary (via actions, different
> > user authorisations) is still a very good thing to have.
> >
> >
> You could knock together have a dedicated Javascript app hitting our REST
> API, then provide an action returning a URL to "launch" that viewer as a
> different tab.
>
>
>
>
> >
> >
> > I kind of see your point, but maybe it would be nice to make this
> > configurable, that is non-edit is default and you add actions to change
> > state, or, edit as default and no actions needed? (the later to please us
> > crudites, its a web-form mode I feel).
> >
> >
> Actually, this is already configurable. I've left the simpleapp archetype
> to have edit mode as default, but this could change in the future.
>
> At any rate, use isis.objects.editing [2]
>
>
>
> >
> > Just moving the edit icon to the right as a short-term option would be
> > good.
> >
> >
>
> I played around with this a bit; the following CSS (in application.css)
> moves the existing edit icon overload onto the entry field itself, which I
> think looks rather nice:
>
> div.stringPanel span.editing a.edit {
> margin-top: -20px;
> margin-bottom: 0px;
> margin-right: 5px;
> }
>
> This applies to only string fields; you could adapt for other field types
> by cloning the CSS line for other containing panels ("div.stringPanel...")
>
> HTH
> Dan
>
>
> [1] https://github.com/opensagres/xdocreport
> [2]
>
> http://isis.apache.org/guides/rgcfg.html#_rgcfg_configuring-core_isis-objects-editing
>
Re: 1.12 changes to editing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
within...
On 20 April 2016 at 10:08, Stephen Cameron <st...@gmail.com>
wrote:
>
> The one major concern I have is simply the efficient manual entry of large
> amounts of data, maybe from a paper format, so being able to enter data by
> tabbing without using the mouse is still desired by some. Maybe there is a
> the need for another kind of viewer for this scenario?
>
>
For this, we use isis-module-excel. This allows the upload of an Excel
spreadsheet, which is then processed server-side. We use it for the bulk
upload of new tax tables once a year.
> This conversation has been had before, with the workflow add-on suggested
> as a possible solution. But there is also the scenario of needing a
> printable form. I'd like to be able to maintain one version of a such a
> printable 'form' only, that is to design something that can be printed and
> handed to be people for filling out, but which in its electronic form can
> be used for easy data-entry straight into the database.
>
>
Well, we have isis-module-docx which can be used. I'm a fan of using Word
as the template language; isis-module-docx is actually a port from the
equivalent .NET implementation that I wrote for the big naked objects
system over in Ireland. We've had several implementations of generating
comms over the years, but isis-module-docx equivalent has been the easiest
to work with.
That said, for Estatio we actually just use SQL Server reporting, I
believe. Jeroen has also played with xdocreport [1] which also looks
promising.
> I've considered using Orbeon Forms (an XForms framework) in concert with
> Apache Isis as the solution to this issue. With JAXB support now in Isis it
> does seem like a nice combo, XML from the XForm into Apache Isis (and
> database) via JAXB.
>
>
Maybe... but our first comms implementation over in Ireland was something
similar, using Altova Stylevision along with XML and XSD generated from the
domain model (we used the xmlsnapshotservice). Bottom line is that it was
quite labour intensive to work with.
> >
> > This is where I am departing in that what I have is essentially a CRUD
> app. Such an app with multiple viewers, all easy to maintain, and with the
> capacity for adding complexity where necessary (via actions, different
> user authorisations) is still a very good thing to have.
>
>
You could knock together have a dedicated Javascript app hitting our REST
API, then provide an action returning a URL to "launch" that viewer as a
different tab.
>
>
> I kind of see your point, but maybe it would be nice to make this
> configurable, that is non-edit is default and you add actions to change
> state, or, edit as default and no actions needed? (the later to please us
> crudites, its a web-form mode I feel).
>
>
Actually, this is already configurable. I've left the simpleapp archetype
to have edit mode as default, but this could change in the future.
At any rate, use isis.objects.editing [2]
>
> Just moving the edit icon to the right as a short-term option would be
> good.
>
>
I played around with this a bit; the following CSS (in application.css)
moves the existing edit icon overload onto the entry field itself, which I
think looks rather nice:
div.stringPanel span.editing a.edit {
margin-top: -20px;
margin-bottom: 0px;
margin-right: 5px;
}
This applies to only string fields; you could adapt for other field types
by cloning the CSS line for other containing panels ("div.stringPanel...")
HTH
Dan
[1] https://github.com/opensagres/xdocreport
[2]
http://isis.apache.org/guides/rgcfg.html#_rgcfg_configuring-core_isis-objects-editing
Re: 1.12 changes to editing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 20 April 2016 at 11:06, Óscar Bou - GOVERTIS <o....@govertis.com> wrote:
>
> I also consider really useful a TabOrderService or similar that could
> allow define the tab order for a given Entity.
>
> A default implementation could navigate from top to bottom, left to right,
> by groups.
>
>
Hmm, maybe, though I think the default tabbing is fairly logical...
basically just follows the .layout.xml file. It's all bootstrap3 so
tabbing should "just work". Perhaps some CSS to make the focus "glow"
might be worth adding?
Re: 1.12 changes to editing
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
+1
I also consider really useful a TabOrderService or similar that could allow define the tab order for a given Entity.
A default implementation could navigate from top to bottom, left to right, by groups.
> El 20 abr 2016, a las 11:08, Stephen Cameron <st...@gmail.com> escribió:
>
> Thanks for the detailed explanation, and I am just as interested to hear
> others opinions too.
>
> Taking a nationalist (fellow Aussie) stance, if thats the way Jira does it
> then its probably good. ;)
>
> The one major concern I have is simply the efficient manual entry of large
> amounts of data, maybe from a paper format, so being able to enter data by
> tabbing without using the mouse is still desired by some. Maybe there is a
> the need for another kind of viewer for this scenario?
>
> This conversation has been had before, with the workflow add-on suggested
> as a possible solution. But there is also the scenario of needing a
> printable form. I'd like to be able to maintain one version of a such a
> printable 'form' only, that is to design something that can be printed and
> handed to be people for filling out, but which in its electronic form can
> be used for easy data-entry straight into the database.
>
> I've considered using Orbeon Forms (an XForms framework) in concert with
> Apache Isis as the solution to this issue. With JAXB support now in Isis it
> does seem like a nice combo, XML from the XForm into Apache Isis (and
> database) via JAXB.
>
> See a few inline comments below
>
>
> On Wed, Apr 20, 2016 at 4:28 PM, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
>> Hi Steve,
>>
>> Thanks for the feedback.
>>
>> There are several reasons why I've made this change, some practical, some
>> more philosophical.
>>
>> 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 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.
>>
>> This is where I am departing in that what I have is essentially a CRUD
> app. Such an app with multiple viewers, all easy to maintain, and with the
> capacity for adding complexity where necessary (via actions, different
> user authorisations) is still a very good thing to have.
>
>
>> 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.
>>
>> So I don't think that de-emphasising edit mode takes us away from the naked
>> objects pattern.
>
> I kind of see your point, but maybe it would be nice to make this
> configurable, that is non-edit is default and you add actions to change
> state, or, edit as default and no actions needed? (the later to please us
> crudites, its a web-form mode I feel).
>
>>
>> In terms of changes to the viewer... as I say: eventually I intend to
>> implement in-place edits, which will remove the buttons. Another
>> short-term option might be to move the edit icon to the right of the field
>> (same place that actions go if positioned to the right). A medium term
>> option might be to introduce an edit button for the entire fieldset, but
>> I'm not completely convinced that it's necessary.
>
> Just moving the edit icon to the right as a short-term option would be
> good.
>
>>
>> (By the way, the change has nothing to do with JAXB view models being
>> editable).
>>
>> Let me know your thoughts... and others reading this, too, please!
>>
>> Thx
>> Dan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 20 April 2016 at 03:00, Stephen Cameron <st...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I want to give a little feed-back on the addition of the edit button to
>> the
>>> bottom right of each editable control. I note that this is probably a
>>> temporary thing but I'm not very keen on it so encourage a change to be
>>> made.
>>>
>>> My problems with it are that its pushes the next control down the page
>> and
>>> wastes space, and it means more actions if you are editing more than one
>>> item.
>>>
>>> One solution is to make all controls non-editable and provide a
>> mass-update
>>> action inside each group, this seems common in Estatio, but I don't see
>> it
>>> as a good practice get into, unless common workflows suggest it, there
>> is a
>>> far bit of work to do it and it seems to take you away from the Naked
>>> Objects paradigm.
>>>
>>> The question is what is the best solution?
>>>
>>> Personally I thought the global Edit (mode) button was fine, its pretty
>>> standard. But placing it in the left column under all the groups did have
>>> the undesirable effect of pushing it down out of sight sometimes. With
>> tabs
>>> that is not a good solution either, i.e on the first tab, and putting it
>>> under the tab-panel not any better.
>>>
>>> One solution is to put it into the first 'title' row of the page, but
>>> aligned on the right-hand side to differentiate is from other actions
>> that
>>> might be there, its kind of an action button.
>>>
>>> Having tabs is very welcome though, so now I have a dilemma. Go to 1.12
>> or
>>> wait to see if the edit buttons disappear in 1.13. I am inclined to stay
>> at
>>> 1.11.
>>>
>>> Of course, as mentioned, there were issues associated with making JAXB
>> view
>>> models editable. If this has led to too much complexity in the viewer
>> then
>>> maybe it wasn't such a good move? My concern with that aspect has been
>> that
>>> conflating JAXB and a View-model mode.
>>>
>>> I hope this is of some usefulness.
>>>
>>> Regards
>>> Steve Cameron
>>
Re: 1.12 changes to editing
Posted by Stephen Cameron <st...@gmail.com>.
Thanks for the detailed explanation, and I am just as interested to hear
others opinions too.
Taking a nationalist (fellow Aussie) stance, if thats the way Jira does it
then its probably good. ;)
The one major concern I have is simply the efficient manual entry of large
amounts of data, maybe from a paper format, so being able to enter data by
tabbing without using the mouse is still desired by some. Maybe there is a
the need for another kind of viewer for this scenario?
This conversation has been had before, with the workflow add-on suggested
as a possible solution. But there is also the scenario of needing a
printable form. I'd like to be able to maintain one version of a such a
printable 'form' only, that is to design something that can be printed and
handed to be people for filling out, but which in its electronic form can
be used for easy data-entry straight into the database.
I've considered using Orbeon Forms (an XForms framework) in concert with
Apache Isis as the solution to this issue. With JAXB support now in Isis it
does seem like a nice combo, XML from the XForm into Apache Isis (and
database) via JAXB.
See a few inline comments below
On Wed, Apr 20, 2016 at 4:28 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi Steve,
>
> Thanks for the feedback.
>
> There are several reasons why I've made this change, some practical, some
> more philosophical.
>
> 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 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.
>
> This is where I am departing in that what I have is essentially a CRUD
app. Such an app with multiple viewers, all easy to maintain, and with the
capacity for adding complexity where necessary (via actions, different
user authorisations) is still a very good thing to have.
> 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.
>
> So I don't think that de-emphasising edit mode takes us away from the naked
> objects pattern.
>
I kind of see your point, but maybe it would be nice to make this
configurable, that is non-edit is default and you add actions to change
state, or, edit as default and no actions needed? (the later to please us
crudites, its a web-form mode I feel).
>
> In terms of changes to the viewer... as I say: eventually I intend to
> implement in-place edits, which will remove the buttons. Another
> short-term option might be to move the edit icon to the right of the field
> (same place that actions go if positioned to the right). A medium term
> option might be to introduce an edit button for the entire fieldset, but
> I'm not completely convinced that it's necessary.
>
Just moving the edit icon to the right as a short-term option would be
good.
>
> (By the way, the change has nothing to do with JAXB view models being
> editable).
>
> Let me know your thoughts... and others reading this, too, please!
>
> Thx
> Dan
>
>
>
>
>
>
>
>
>
> On 20 April 2016 at 03:00, Stephen Cameron <st...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I want to give a little feed-back on the addition of the edit button to
> the
> > bottom right of each editable control. I note that this is probably a
> > temporary thing but I'm not very keen on it so encourage a change to be
> > made.
> >
> > My problems with it are that its pushes the next control down the page
> and
> > wastes space, and it means more actions if you are editing more than one
> > item.
> >
> > One solution is to make all controls non-editable and provide a
> mass-update
> > action inside each group, this seems common in Estatio, but I don't see
> it
> > as a good practice get into, unless common workflows suggest it, there
> is a
> > far bit of work to do it and it seems to take you away from the Naked
> > Objects paradigm.
> >
> > The question is what is the best solution?
> >
> > Personally I thought the global Edit (mode) button was fine, its pretty
> > standard. But placing it in the left column under all the groups did have
> > the undesirable effect of pushing it down out of sight sometimes. With
> tabs
> > that is not a good solution either, i.e on the first tab, and putting it
> > under the tab-panel not any better.
> >
> > One solution is to put it into the first 'title' row of the page, but
> > aligned on the right-hand side to differentiate is from other actions
> that
> > might be there, its kind of an action button.
> >
> > Having tabs is very welcome though, so now I have a dilemma. Go to 1.12
> or
> > wait to see if the edit buttons disappear in 1.13. I am inclined to stay
> at
> > 1.11.
> >
> > Of course, as mentioned, there were issues associated with making JAXB
> view
> > models editable. If this has led to too much complexity in the viewer
> then
> > maybe it wasn't such a good move? My concern with that aspect has been
> that
> > conflating JAXB and a View-model mode.
> >
> > I hope this is of some usefulness.
> >
> > Regards
> > Steve Cameron
> >
>
Re: 1.12 changes to editing
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi Dan.
For me Jira has always been an inspiration.
So I would love inbound editing, as it would hide if the property has or not a modifyXXX method associated (or a clearXXX one) when Domain Rules are placed.
That ways there's no need to implement its single change through an action.
Obviously actions will still be needed if the express other intents in addition to execute business logic each time this property is modified (directly or indirectly invoked by actions inside a "wrap(...)").
Thanks,
Oscar
> El 20 abr 2016, a las 8:37, David Soff <da...@soff.nl> escribió:
>
> This is an awesome explanation which should be on the documentation site.
>
>> On Wed, 20 Apr 2016 07:28 Dan Haywood, <da...@haywood-associates.co.uk> wrote:
>>
>> Hi Steve,
>>
>> Thanks for the feedback.
>>
>> There are several reasons why I've made this change, some practical, some
>> more philosophical.
>>
>> 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 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.
>>
>> So I don't think that de-emphasising edit mode takes us away from the naked
>> objects pattern.
>>
>> In terms of changes to the viewer... as I say: eventually I intend to
>> implement in-place edits, which will remove the buttons. Another
>> short-term option might be to move the edit icon to the right of the field
>> (same place that actions go if positioned to the right). A medium term
>> option might be to introduce an edit button for the entire fieldset, but
>> I'm not completely convinced that it's necessary.
>>
>> (By the way, the change has nothing to do with JAXB view models being
>> editable).
>>
>> Let me know your thoughts... and others reading this, too, please!
>>
>> Thx
>> Dan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 20 April 2016 at 03:00, Stephen Cameron <st...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I want to give a little feed-back on the addition of the edit button to
>> the
>>> bottom right of each editable control. I note that this is probably a
>>> temporary thing but I'm not very keen on it so encourage a change to be
>>> made.
>>>
>>> My problems with it are that its pushes the next control down the page
>> and
>>> wastes space, and it means more actions if you are editing more than one
>>> item.
>>>
>>> One solution is to make all controls non-editable and provide a
>> mass-update
>>> action inside each group, this seems common in Estatio, but I don't see
>> it
>>> as a good practice get into, unless common workflows suggest it, there
>> is a
>>> far bit of work to do it and it seems to take you away from the Naked
>>> Objects paradigm.
>>>
>>> The question is what is the best solution?
>>>
>>> Personally I thought the global Edit (mode) button was fine, its pretty
>>> standard. But placing it in the left column under all the groups did have
>>> the undesirable effect of pushing it down out of sight sometimes. With
>> tabs
>>> that is not a good solution either, i.e on the first tab, and putting it
>>> under the tab-panel not any better.
>>>
>>> One solution is to put it into the first 'title' row of the page, but
>>> aligned on the right-hand side to differentiate is from other actions
>> that
>>> might be there, its kind of an action button.
>>>
>>> Having tabs is very welcome though, so now I have a dilemma. Go to 1.12
>> or
>>> wait to see if the edit buttons disappear in 1.13. I am inclined to stay
>> at
>>> 1.11.
>>>
>>> Of course, as mentioned, there were issues associated with making JAXB
>> view
>>> models editable. If this has led to too much complexity in the viewer
>> then
>>> maybe it wasn't such a good move? My concern with that aspect has been
>> that
>>> conflating JAXB and a View-model mode.
>>>
>>> I hope this is of some usefulness.
>>>
>>> Regards
>>> Steve Cameron
>>
Re: 1.12 changes to editing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Pull requests accepted for documentation pages too...!
Perhaps add something to the release notes page for 1.12.0, at least?
On 20 Apr 2016 7:38 am, "David Soff" <da...@soff.nl> wrote:
> This is an awesome explanation which should be on the documentation site.
>
> On Wed, 20 Apr 2016 07:28 Dan Haywood, <da...@haywood-associates.co.uk>
> wrote:
>
> > Hi Steve,
> >
> > Thanks for the feedback.
> >
> > There are several reasons why I've made this change, some practical, some
> > more philosophical.
> >
> > 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 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.
> >
> > So I don't think that de-emphasising edit mode takes us away from the
> naked
> > objects pattern.
> >
> > In terms of changes to the viewer... as I say: eventually I intend to
> > implement in-place edits, which will remove the buttons. Another
> > short-term option might be to move the edit icon to the right of the
> field
> > (same place that actions go if positioned to the right). A medium term
> > option might be to introduce an edit button for the entire fieldset, but
> > I'm not completely convinced that it's necessary.
> >
> > (By the way, the change has nothing to do with JAXB view models being
> > editable).
> >
> > Let me know your thoughts... and others reading this, too, please!
> >
> > Thx
> > Dan
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 20 April 2016 at 03:00, Stephen Cameron <st...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I want to give a little feed-back on the addition of the edit button to
> > the
> > > bottom right of each editable control. I note that this is probably a
> > > temporary thing but I'm not very keen on it so encourage a change to be
> > > made.
> > >
> > > My problems with it are that its pushes the next control down the page
> > and
> > > wastes space, and it means more actions if you are editing more than
> one
> > > item.
> > >
> > > One solution is to make all controls non-editable and provide a
> > mass-update
> > > action inside each group, this seems common in Estatio, but I don't see
> > it
> > > as a good practice get into, unless common workflows suggest it, there
> > is a
> > > far bit of work to do it and it seems to take you away from the Naked
> > > Objects paradigm.
> > >
> > > The question is what is the best solution?
> > >
> > > Personally I thought the global Edit (mode) button was fine, its pretty
> > > standard. But placing it in the left column under all the groups did
> have
> > > the undesirable effect of pushing it down out of sight sometimes. With
> > tabs
> > > that is not a good solution either, i.e on the first tab, and putting
> it
> > > under the tab-panel not any better.
> > >
> > > One solution is to put it into the first 'title' row of the page, but
> > > aligned on the right-hand side to differentiate is from other actions
> > that
> > > might be there, its kind of an action button.
> > >
> > > Having tabs is very welcome though, so now I have a dilemma. Go to 1.12
> > or
> > > wait to see if the edit buttons disappear in 1.13. I am inclined to
> stay
> > at
> > > 1.11.
> > >
> > > Of course, as mentioned, there were issues associated with making JAXB
> > view
> > > models editable. If this has led to too much complexity in the viewer
> > then
> > > maybe it wasn't such a good move? My concern with that aspect has been
> > that
> > > conflating JAXB and a View-model mode.
> > >
> > > I hope this is of some usefulness.
> > >
> > > Regards
> > > Steve Cameron
> > >
> >
>
Re: 1.12 changes to editing
Posted by David Soff <da...@soff.nl>.
This is an awesome explanation which should be on the documentation site.
On Wed, 20 Apr 2016 07:28 Dan Haywood, <da...@haywood-associates.co.uk> wrote:
> Hi Steve,
>
> Thanks for the feedback.
>
> There are several reasons why I've made this change, some practical, some
> more philosophical.
>
> 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 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.
>
> So I don't think that de-emphasising edit mode takes us away from the naked
> objects pattern.
>
> In terms of changes to the viewer... as I say: eventually I intend to
> implement in-place edits, which will remove the buttons. Another
> short-term option might be to move the edit icon to the right of the field
> (same place that actions go if positioned to the right). A medium term
> option might be to introduce an edit button for the entire fieldset, but
> I'm not completely convinced that it's necessary.
>
> (By the way, the change has nothing to do with JAXB view models being
> editable).
>
> Let me know your thoughts... and others reading this, too, please!
>
> Thx
> Dan
>
>
>
>
>
>
>
>
>
> On 20 April 2016 at 03:00, Stephen Cameron <st...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I want to give a little feed-back on the addition of the edit button to
> the
> > bottom right of each editable control. I note that this is probably a
> > temporary thing but I'm not very keen on it so encourage a change to be
> > made.
> >
> > My problems with it are that its pushes the next control down the page
> and
> > wastes space, and it means more actions if you are editing more than one
> > item.
> >
> > One solution is to make all controls non-editable and provide a
> mass-update
> > action inside each group, this seems common in Estatio, but I don't see
> it
> > as a good practice get into, unless common workflows suggest it, there
> is a
> > far bit of work to do it and it seems to take you away from the Naked
> > Objects paradigm.
> >
> > The question is what is the best solution?
> >
> > Personally I thought the global Edit (mode) button was fine, its pretty
> > standard. But placing it in the left column under all the groups did have
> > the undesirable effect of pushing it down out of sight sometimes. With
> tabs
> > that is not a good solution either, i.e on the first tab, and putting it
> > under the tab-panel not any better.
> >
> > One solution is to put it into the first 'title' row of the page, but
> > aligned on the right-hand side to differentiate is from other actions
> that
> > might be there, its kind of an action button.
> >
> > Having tabs is very welcome though, so now I have a dilemma. Go to 1.12
> or
> > wait to see if the edit buttons disappear in 1.13. I am inclined to stay
> at
> > 1.11.
> >
> > Of course, as mentioned, there were issues associated with making JAXB
> view
> > models editable. If this has led to too much complexity in the viewer
> then
> > maybe it wasn't such a good move? My concern with that aspect has been
> that
> > conflating JAXB and a View-model mode.
> >
> > I hope this is of some usefulness.
> >
> > Regards
> > Steve Cameron
> >
>
Re: 1.12 changes to editing
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Steve,
Thanks for the feedback.
There are several reasons why I've made this change, some practical, some
more philosophical.
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 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.
So I don't think that de-emphasising edit mode takes us away from the naked
objects pattern.
In terms of changes to the viewer... as I say: eventually I intend to
implement in-place edits, which will remove the buttons. Another
short-term option might be to move the edit icon to the right of the field
(same place that actions go if positioned to the right). A medium term
option might be to introduce an edit button for the entire fieldset, but
I'm not completely convinced that it's necessary.
(By the way, the change has nothing to do with JAXB view models being
editable).
Let me know your thoughts... and others reading this, too, please!
Thx
Dan
On 20 April 2016 at 03:00, Stephen Cameron <st...@gmail.com>
wrote:
> Hi,
>
> I want to give a little feed-back on the addition of the edit button to the
> bottom right of each editable control. I note that this is probably a
> temporary thing but I'm not very keen on it so encourage a change to be
> made.
>
> My problems with it are that its pushes the next control down the page and
> wastes space, and it means more actions if you are editing more than one
> item.
>
> One solution is to make all controls non-editable and provide a mass-update
> action inside each group, this seems common in Estatio, but I don't see it
> as a good practice get into, unless common workflows suggest it, there is a
> far bit of work to do it and it seems to take you away from the Naked
> Objects paradigm.
>
> The question is what is the best solution?
>
> Personally I thought the global Edit (mode) button was fine, its pretty
> standard. But placing it in the left column under all the groups did have
> the undesirable effect of pushing it down out of sight sometimes. With tabs
> that is not a good solution either, i.e on the first tab, and putting it
> under the tab-panel not any better.
>
> One solution is to put it into the first 'title' row of the page, but
> aligned on the right-hand side to differentiate is from other actions that
> might be there, its kind of an action button.
>
> Having tabs is very welcome though, so now I have a dilemma. Go to 1.12 or
> wait to see if the edit buttons disappear in 1.13. I am inclined to stay at
> 1.11.
>
> Of course, as mentioned, there were issues associated with making JAXB view
> models editable. If this has led to too much complexity in the viewer then
> maybe it wasn't such a good move? My concern with that aspect has been that
> conflating JAXB and a View-model mode.
>
> I hope this is of some usefulness.
>
> Regards
> Steve Cameron
>