thanks
On Thu, Apr 21, 2016 at 4:47 PM, Dan Haywood <[email protected]> wrote: > within... > > > On 20 April 2016 at 10:08, Stephen Cameron <[email protected]> > 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 >
