Guido,
> It is not necessary to completely hide some fields, we could use AJAX
Maybe we could incorporate Prototype (http://www.prototypejs.org/)? Build a convenient engine
around AJAX that the OFBiz framework can easily talk to?
> 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.
The above is currently done without AJAX. See
facility/control/EditInventoryItem?inventoryItemId=9000&facilityId=WebStoreWarehouse with the demo
data for example. Changing the "InventoryItem Type ID" between Serialized and Non-Serialized will
show you different fields.
IMO, that's fine. We do have to be careful with AJAX. Doing it wrong can cause security problems,
database overload problems, etc.
> 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.
THAT is what I've been pushing for too! Anyway, I'm also happy that the OFBiz community is
focusing more time on improving/debugging OFBiz (and neglecting docs aspect).
But your suggestion won't even see light of day, at least not until someone DOES do a proper
comprehensive doc of OFBiz (ERP aspect, not framework). As it is now, I often ask questions about
OFBiz-ERP that even veterans don't know how to answer offhand (what with 600,000++ lines of codes
and 700+ database tables!).
For example, I'd do a quick scan (don't ask how, long story) of OFBiz to find that lotId (for lot
control) has scaffolding in database but is not implemented on front-end forms. I would then ask a
question to community like "can anyone confirm that function is not yet completed, so I can do
it?". I used to ask questions like "Can anyone tell me if that function exists?", to which I get a
response to effect of "Would you like to pay somebody to train you to find that answer, or to do
that function for you?".
No, to be fair, it doesn't always happen that way. I believe it often happens because the
community really hasn't documented OFBiz-ERP enough to give me a quick answer.
Jonathon
Guido Amarilla wrote:
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
