the one thing i did not consider was behavior of chained requests,
however if what you says is true then that is mute.
the current pre-process would be tagged default and the URI tag would be
default which is the same thing you describe is the current behavior
only the code that deals with this has to be modified.
once the code is changed to handle this then adding a new preprocessor
with its own tag would not effect the chained requests, unless I am
still missing something.
this could also allow for more than one preprocess per URI.
Scott Gray sent the following on 2/15/2011 8:04 PM:
Hi BJ,
That could get pretty complicated (chained requests for example would make this
difficult) and you'd still need to tag every request that requires a certain
event to be run which would be a pain. Also preprocessor events are intended
to be run on every request so I'm not sure how you'd maintain that behavior
properly while enabling what you're suggesting.
Thanks
Scott
On 16/02/2011, at 12:54 PM, BJ Freeman wrote:
how about putting a tag on the pre-processor
then include the tag in the URi spec
when the URI is accessed it uses the pre-processor in the tag.
doubt either way would make much difference at controller reload IO.
=========================
BJ Freeman
Strategic Power Office with Supplier
Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com<http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Scott Gray sent the following on 2/15/2011 2:40 PM:
I regularly run into a situation where I need a pre-processor event to run only
for a sub-set of a webapp's requests, usually within a particular group of
screens (an example might be that you want to check that a specific session
attribute or request parameter is set before allowing access to that set of
requests). Currently you can only run an event for either a single request
(request-map.event) or for every request (preprocessor.event) within a webapp,
there isn't really any in-between.
I threw together a quick PoC this morning for a sub-controller implementation
that would allow a webapp to have multiple controllers. Basically you have
your regular controller at /control/ but within the controller.xml you can
define sub-controllers and the path that it should use:
Main controller.xml
<sub-controller location="component://example/webapp/example/WEB-INF/sub-controller.xml"
path="sub"/>
now every request to /control/sub/* will use the sub-controller.xml instead of
the main controller and is handled in exactly the same way as the main
controller would be.
Any thoughts?
Thanks
Scott
HotWax Media
http://www.hotwaxmedia.com
