Posted by
Guido Amarilla on
Jan 22, 2007; 6:13am
URL: http://ofbiz.116.s1.nabble.com/Simple-backend-UI-enhancement-proposition-tp143920p143927.html
It is not necessary to completely hide some fields, we could use AJAX
visibility and some option to change it without a page reload. It
could be a good idea to fill the form´s default values on BEFORE form
load, and not only if the user didn´t fill a field after submitting
the form. Tab navigation and form sectorization is a great idea too
(much better with AJAX).
I am thinking of some kind of runtime templating for the visibility of
fields. It could be implemented in AJAX. For example you have the New
Product Creation form with lots of fields, and you could have a
dropdown to select the type of product and according to the selected
option you can hide some form fields that are not relevant (having the
"All Fields" option on top or bottom for advanced users). You could
load some default values in some fields and if the user wants, could
be changed.
I don´t know OFBiz so much yet but I think that something like this
could help "cleaning" the screens in some places.
It could be very useful for new users to have a help icon link next to
each field or for each form with a full explanation of each field and
examples.
Another important feature, is to visually mark wich are the mandatory
fields in a form. I think that there is a JIRA issue for that.
Guido Amarilla
2007/1/22, Jonathon -- Improov <
[hidden email]>:
> Why don't we reuse the existing permissions infrastructure (no new Form meta data in database),
> and simply code the front-end to show/hide fields based on those permissions?
>
> Jonathon
>
> Anil Patel wrote:
> > yes we can also say that. true.
> >
> >
> >
> > On 1/21/07, David E. Jones <
[hidden email]> wrote:
> >>
> >>
> >> So, you're thinking of more of a permission system?
> >>
> >> -David
> >>
> >>
> >> On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:
> >>
> >> > If we have Form meta data in Database then we can enhance the screen
> >> > rendering system to read field visibility attribute from the database.
> >> > So lets say, userLogin.userId belongs to Casher User group. So when
> >> > rendering a ScreenA::FormX, System will look for visibility
> >> > attributes of
> >> > fields on FormX as part of ScreenA for Casher userGroup.
> >> >
> >> > I have seen PeopleSoft does this.
> >> >
> >> > Regards
> >> > Anil Patel
> >> >
> >> > On 1/21/07, David E. Jones <
[hidden email]> wrote:
> >> >>
> >> >>
> >> >> On Jan 21, 2007, at 6:33 AM, Anil Patel wrote:
> >> >>
> >> >> > This is great, Can we do this, Save Screen and Form definition in
> >> >> > Database
> >> >> > (Sceeen and Form widget file will loaded into database.), Party
> >> >> Group
> >> >> > Preferences set of Entities can be designed to store the
> >> >> > information like
> >> >> > which field should be visible/hidden for a Party Group..
> >> >> > By doing this we can customize what user sees on the Screen.
> >> >>
> >> >> This sounds quite a bit different from what Jacques was proposing,
> >> >> but if I understand right what you are proposing this is something
> >> >> I'm happy to write long and loud against.
> >> >>
> >> >> What would we gain by putting these things into the database?
> >> >>
> >> >> What will we lose by putting these things into the database?
> >> >>
> >> >> I'm interested in your thoughts so I won't answer these quite yet,
> >> >> though if you (or anyone) is interested in my answer this is
> >> >> something I've written about in the past quite a bit and you'll find
> >> >> stuff in the old mailing list archives. Still, I'd rather hear
> >> >> other's opinions about it before I express my own, just to make sure
> >> >> I don't miss anything that people might not want to say when I come
> >> >> down hard on this. As I mentioned above, I have very strong opinions
> >> >> about this and these are based on some very bad experiences.
> >> >>
> >> >> -David
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.17.4/643 - Release Date: 1/21/2007 5:12 PM
>
>
--
Guido Amarilla