Posted by
jonwimp on
Jan 22, 2007; 4:06am
URL: http://ofbiz.116.s1.nabble.com/Simple-backend-UI-enhancement-proposition-tp143920p143939.html
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 (in database) are not mandatory, so no harm cutting them out on
front-end forms. I believe (hope) that David and other committers have guided OFBiz-ERP
development in such a way that data structures remain as flexible as possible, allowing
customizers to slap on constraints themselves if they do want to use the non-mandatory fields. If
that is so, I don't see a problem in simply cutting of front-end form fields we don't need (let
the unused values be null in database).
Moreover, and this can be a big one, why would we want to burden the database with front-end
forms? I can see why we have to store images (company logos) in database, but not why we should
make OFBiz a flexible "design your entire storefront and ERP screens from ground-up" solution.
Server performance is major concern here.
Added complexity and reduced flexibility can also happen. Say you have certain flags (alright, not
full form definitions) in database that dictate whether certain fields are shown or not. Doesn't
that restrict my freedom to cut out some fields from front-end forms? I take one field out
unwittingly from front-end form, I'll possibly get a nullpointer error somewhere propagated from
database upwards.
At any rate, I don't see much ROI here. Seems more trouble than it's worth. Spend effort on
something else?
Just my 2 cents.
Jonathon
David E. Jones 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
>