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
