|
nk4um Moderator
Posts: 485
|
2010-02-23T12:10:53.000ZFebruary 23, 2010 12:10Yes!
|
In addition, if I defined an pluggable overlay in a module (urn:infrastructure:overlay) and wrapped all my other modules in
that space, could I then dynamically import the overlay into the front-end fulcrum rather than dynamically importing each
of the wrapped modules?
|
Yes you certainly can. That is a good way to achieve the result you want. The control panel uses that pattern to ensure each
tool gets wrapped with a template. Tony
|
|
nk4um Moderator
Posts: 485
|
2010-02-23T12:08:37.000ZFebruary 23, 2010 12:08
Hi, the pluggable overlay only supports a single preProcess and/or postProcess. There are three ways to achieve the pipes&filters
pattern.
Firstly you can use the branch-merge accessor which instantiates a set of pipes for different subsets of the address space
and channels all request/responses through a set of overlays. This is the best approach if you have lots of logical channels
which want different overlay behaviours.
Secondly you can just nest pluggable overlays in the module definition. This is simplest if every request wants the same behaviour
(I think this is what you need for this example)
Thirdly you can created nested requests using the new nested request capability of declarative request. This approach doesn''t
use overlays so it a more dynamic but might not be suitable for your example.
Tony
|
|
nk4um User
Posts: 79
|
This is example is taken from the REST tutorial.
<pluggable-overlay>
<preProcess>
<identifier>active:java</identifier>
<argument name="class">tutorial.rest.part4.part4b.HTTPVerbTranslationAccessor</argument>
<argument name="request">arg:request</argument>
</preProcess>
<space>
<mapper>
<config>res:/tutorial/rest/part4/part4b/mapperConfig.xml</config>
<space>
<fileset>
<regex>res:/tutorial/rest/part4/part4b/.*</regex>
</fileset>
<import>
<uri>urn:org:netkernel:ext:layer1</uri>
</import>
</space>
</mapper>
</space>
</pluggable-overlay>
|
Can a pluggable overlay have many pre-processors (Pipes & Filters pattern)? In other words could I add another audit pre-process
and it would be called next (with the results from the first pre-process) before calling the wrapped space?
<pluggable-overlay>
<preProcess>
<identifier>active:java</identifier>
<argument name="class">tutorial.rest.part4.part4b.HTTPVerbTranslationAccessor</argument>
<argument name="request">arg:request</argument>
</preProcess>
<preProcess>
<identifier>active:java</identifier>
<argument name="class">tutorial.rest.part4.part4b.AuditAccessor</argument>
<argument name="request">arg:request</argument>
</preProcess>
<space>
<mapper>
<config>res:/tutorial/rest/part4/part4b/mapperConfig.xml</config>
<space>
<fileset>
<regex>res:/tutorial/rest/part4/part4b/.*</regex>
</fileset>
<import>
<uri>urn:org:netkernel:ext:layer1</uri>
</import>
</space>
</mapper>
</space>
</pluggable-overlay>
|
In addition, if I defined an pluggable overlay in a module (urn:infrastructure:overlay) and wrapped all my other modules in
that space, could I then dynamically import the overlay into the front-end fulcrum rather than dynamically importing each
of the wrapped modules?
|
