Users - location parameter on the request-map in the controller.xml file

[cjhowe]

There's been general consensus that this would be
"useful", but as David J. has mentioned, would then
make it rather dificult to track down where the
request was coming from.  

I think most people who extend, test and debug new
applications/custom applications do so by navigating
the application through a browser and when they come
across something they don't like or want to change
take the url->controller->request->etc approach in
tracking down where to make a change/inspect the
logic.  By importing from other controllers or xml you
break that trail.

If you could apply a stylesheet to the runtime
controller (and have an xml parser available when
OFBiz isn't running that's aware of the component://
structure) you could have the request map group
labeled and thus overcome the drawback of doing this.


==========Andrew Sykes wrote:

Hans,

This sounds like a good idea.

Perhaps it would be better if the resource could be
renamed in the new
context i.e.

<request-map uri="newname"
location="component://party/webapp/partymgr/WEB-
INF/controller.xml#oldname"/>

Kind Regards
--
Andrew Sykes <andrew at sykesdevelopment.com>
Sykes Development Ltd
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

Chris,

I don't really understand why this would create such a difficult "twist"
in the trail.

The format of this would be the same as that for the widget/form stuff.

If anything, I would imagine having a build step would make things a lot
more complicated, imagine what a headache it would be tracking
down/modifying a request that was generated during the build!

With Han's suggestion, you could (if you wanted) reduce the number of
lines in controller.xml pretty significantly. For example all the
generic login stuff could be declared somewhere in security and then
referenced in a single line in each app's controller.xml

You could then, if you wanted go a step further (bear with me!) and
define groups further reducing the lines of code!?! - This would make
setting up derivative webapps much quicker. Although the complex
interdependencies might outweigh the benefits. Not sure that's a good
idea, but I'd be interested to see what you think...

Perhaps on a more sober note, this functionality would be a useful
addition to those creating derivative works though not necessarily used
in the core OFBiz...

Kind Regards
--
Andrew Sykes <[hidden email]>
Sykes Development Ltd

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