On Jan 26, 2009, at 8:27 PM, Hans Bakker wrote:
David,
ok i understand, however that means we have to asd the retrieval/
display
of the logged in party/defaultOrganizationParty in every application
component?
Yes, each component would need to have a few lines in the actions of
the screen def for the "main-decorator" screen (I think always called
that, and always in the CommonScreens.xml file). It would be just like
the labels files thingy, ie with a list of set operations.
i still think there is a need for an application-decorator between the
application and the global-decorator.
You're right, there is no such thing right now. If it is too much of a
pain to maintain these things in the various main-decorator screens it
might make sense.
This would be a good part of the applications common component
(something like appcommon to be different from the framework/common
component) that Jacopo proposed. However, doing anything like this,
wherever we do it, does lead a very funny dependency issue and if we
did it in the appcommon component: the appcommon component would
depend on various other applications components, AND those other
applications components would depend on the appcommon component (ie a
circular dependency)...
I guess if there is anything I dislike more than redundancy it is
circular dependencies... but maybe the circular dependencies won't
cause us any problems in this case...
-David
On Mon, 2009-01-26 at 12:33 -0700, David E Jones wrote:
On Jan 26, 2009, at 1:53 AM, Hans Bakker wrote:
David,
see below....
On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
....
There are various things in the framework now that have general
infrastructure that applications can "plugin" to, and I think we
could
follow that same pattern here.
if you can tell me how to insert 'action' and 'widget' statements in
the
common/widget/commonscreens.xml decorators from a lower level
component,
I am very happy to do that.
The main tool to combine actions and widgets is the screen widget, so
including screens would be the natural way to get this information
shown in the header. In a way the header is too big right now anyway,
ie the code is all in one big block and such, and it would be nice to
have it more parameterized and organized, and easier to customize...
perhaps even with preferences and what what (seems to be the general
direction we're going).
What I was saying about the CSS and JS files is that we have a list
of
those files to include for those, and for things to go in the header
we could create a similar list of screens to include, and just loop
through it (in the header.ftl file) and include each one using the
screens.include thingy. These would just be little informational
screenlets to show stuff in the header, just like these things you've
added (ie the organization party, even others like the currency,
etc).
I hope that helps.
-David
--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....
