After an exchange with Ian McNulty about UI clarification, I thought a bit for
a solution (actually I did not thought a lot, the idea was there, clear, when I
waked up ;o)
Ian is not the 1st to complain about backend complexity. Yes, my propostion is
only about backend. Because IMO eCommerce an
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 c
So, how do we decide which fields are required (mandatory) or not?
-David
On Jan 21, 2007, at 4:28 AM, Jacques Le Roux wrote:
After an exchange with Ian McNulty about UI clarification, I
thought a bit for a solution (actually I did not thought a lot, the
idea was there, clear, when I wake
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 vi
Jacques,
On your suggestion, I think it would only make sense to make a subset of
the features if there was clear market evidence of what the subset would
be and who would benefit from it.
As I don't think anything like this is currently available, I'm inclined
to think that going in this directi
Yes, that's most part of the work. I will think about it and elaborate more my
proposition. Of course any help is welcome.
I guess we will have to make a consensus about which fields are preferably
shown. I regret to have used "mandatory" or even
"required" as this has no sense as I previously wr
sage -
From: "Andrew Sykes" <[EMAIL PROTECTED]>
To:
Sent: Sunday, January 21, 2007 11:06 PM
Subject: Re: Simple backend UI enhancement proposition
> Jacques,
>
> On your suggestion, I think it would only make sense to make a subset of
> the features if there was
Okay, now behind curtain #2...
The whole point of my question was to get you and others thinking.
The policy on this was established years ago.
For OFBiz OOTB the point is to be as inclusive as possible. There is
one reason for this: it is easier to know something is there and
decide you
t-in-an-ERP" ?
> What defined this fields exactly ?
> Why are they all put on a single screen ?
> Why not using tabs on such a screen to hide unnecessary complexity and break
> this overload of information (BTW I'm convinced that
> tabs in form widget would be a must to have) ?
I agree with David here.
First off, how difficult is it to "customize" OFBiz and cut away some fields from the forms? If a
business only ever uses certain fields, what's the point of hiding the others away
programmatically? Why not just cut the front-end forms?
As I told my boss, many fields
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
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 Cashe
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 rea
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:
S
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
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 visi
FYI - there are examples of use of dojo in OFBiz at the moment.
Check out the quick anonymous checkout process whenever you get a
chance. We have built a number of user interface enhancements using
this package.
You can also easily use hidden divs,etc with very simple javascript -
to ge
On Jan 22, 2007, at 12:03 AM, Jonathon -- Improov wrote:
> 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 OF
rom: "David E. Jones" <[EMAIL PROTECTED]>
To:
Cc: "Tom Anderson" <[EMAIL PROTECTED]>; "Ian McNulty" <[EMAIL PROTECTED]>
Sent: Monday, January 22, 2007 8:53 AM
Subject: Re: Simple backend UI enhancement proposition
>
> On Jan 22, 2007, at 12:03 AM
-
From: "David E. Jones" <[EMAIL PROTECTED]>
To:
Cc: "Tom Anderson" <[EMAIL PROTECTED]>; "Ian McNulty"
<[EMAIL PROTECTED]>
Sent: Monday, January 22, 2007 8:53 AM
Subject: Re: Simple backend UI enhancement proposition
On Jan 22, 2007, at 12:03 A
Thanks for tips Florin
Jacques
- Original Message -
From: "Florin Jurcovici" <[EMAIL PROTECTED]>
To:
Sent: Monday, January 22, 2007 1:20 PM
Subject: Re: Simple backend UI enhancement proposition
> Hello.
>
> Not in ofbiz, but in some Domino-backed web fro
21 matches
Mail list logo
