[OFBiz] Dev - General Application Goals for OFBiz

[David E. Jones]

There has been some recent discussion about this and some seem to get  
it quite well and others not so well, so hopefully this will clear  
some things up...

To limit the scope short of infinite and something reasonable and  
usable we are creating stock applications that have full  
functionality and full fields and are organized generically according  
to data structure.

For specific roles/users and custom applications new screens specific  
to a task can be created. This is often a major part of  
customization, and at some point we may create collections of screens  
mostly derived from other screens/forms/etc to reuse resources where  
possible to make them easier to maintain.

Even with the existence of the role/task/etc specific screens we  
don't want to eliminate the more general ones, not ever, because  
cases may arise that are not expected (they always do) and the more  
general screens with all fields and such are sometimes needed.

To customize a screen or create a derived form with fields left out  
from the original form, the form widget with ignore type fields and  
such can be used. This leaves much simpler code with the general  
tools used to make it easier to customize and such. Adding flags for  
every fields would be quite cumbersome and has no real place in the  
general applications. In customized applications inherited forms with  
ignore type fields for the ones to leave out should be used.

Note that this is different from the concept of a user being able to  
hide/move/add/etc fields and that is something that we have not yet  
implemented with the form widget and supporting tools, but something  
that has been discussed and that we may do in the future. Still,  
those would be per-user settings in the database and the more general  
customization to the screens and forms would still be done in the  
traditional way.

This is a very important pattern for the general progress of the  
project and should always be kept in mind when working on the general  
functionality in the project.

-David


 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

[Si Chen-2]

David,

Where should these user/role/task specific screens be located?  Should
we have a separate set of UI within the existing OFBiz applications?  
For example, I think the new packing screens in facility are excellent
but basically duplicate the functions of the shipment screens.  Is this
a pattern that you like going forward?  Or, should they be separate
applications with OFBiz?  Or just developed separately altogether?

The reason I ask is that I think it is very important to have quick and
easy to use interface to attract more users, developers, and sponsors.  
Our commercial competitors are armed with glossy brochures and jazzy
demos, and potential decisionmakers will probably be managers who would
expect a polished look.  In addition, other open source applications are
just a click away on the web as well.

Si

David E. Jones wrote:

>
> There has been some recent discussion about this and some seem to get  
> it quite well and others not so well, so hopefully this will clear  
> some things up...
>
> To limit the scope short of infinite and something reasonable and  
> usable we are creating stock applications that have full  
> functionality and full fields and are organized generically according  
> to data structure.
>
> For specific roles/users and custom applications new screens specific  
> to a task can be created. This is often a major part of  
> customization, and at some point we may create collections of screens  
> mostly derived from other screens/forms/etc to reuse resources where  
> possible to make them easier to maintain.
>
> Even with the existence of the role/task/etc specific screens we  
> don't want to eliminate the more general ones, not ever, because  
> cases may arise that are not expected (they always do) and the more  
> general screens with all fields and such are sometimes needed.
>
> To customize a screen or create a derived form with fields left out  
> from the original form, the form widget with ignore type fields and  
> such can be used. This leaves much simpler code with the general  
> tools used to make it easier to customize and such. Adding flags for  
> every fields would be quite cumbersome and has no real place in the  
> general applications. In customized applications inherited forms with  
> ignore type fields for the ones to leave out should be used.
>
> Note that this is different from the concept of a user being able to  
> hide/move/add/etc fields and that is something that we have not yet  
> implemented with the form widget and supporting tools, but something  
> that has been discussed and that we may do in the future. Still,  
> those would be per-user settings in the database and the more general  
> customization to the screens and forms would still be done in the  
> traditional way.
>
> This is a very important pattern for the general progress of the  
> project and should always be kept in mind when working on the general  
> functionality in the project.
>
> -David
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev