On 9/20/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>>From: "Ryan Wynn" <[EMAIL PROTECTED]>
>>
>> Just wondering how dependent the clay plugin is on shale core. I
>> heavily depend on clay in my app but shale core is a bit too
>> progressive for my app server - which is okay. But is there way I can
>> use clay independent of core? Last time I checked it was only loosely
>> married by virtue of some utility classes. It would be really helpful
>> to me if these 2 were more loosely coupled. Right now I have to use a
>> combination of core-1.0.2 with clay-1.0.3 for my application to work
>> and basically core would need to stay at 1.0.2 forever to work with my
>> required app server.
>
>
>The majority of dependencies are with these two handy-dandy utilities.
>
>org.apache.shale.util.Messages
>org.apache.shale.util.Tags
>
>These two are a replacement for allot of what commons bean utils provides but
>with JSF flavor.
>
>org.apache.shale.util.ConverterHelper
>org.apache.shale.util.PropertyHelper
>
One way we might be able to handle it would be to copy the 4 utility classes
into clays utils package.
I saw another thread where Craig was looking to refactor things such
as reading config files into a shared utility jar. Maybe this could
be a home for these classes.
>There are a couple places that we use the commons chains filter commands. One
>is the trigger for looking for modified files and the other has to do with
using
>multiple strategies for view composition in the same app.
>
>org.apache.shale.application.AbstractRegExpFilter
>org.apache.shale.faces.ShaleWebContext
>
These dependencies can be refactored out. We can pull in what
is being reused in the AbstractRegExpFilter and I don't think
we need to cast to the ShaleWebContext to get to the request
and servlet context. We can use the attribute transparency
of it's super.
>The full html and xml views assume the same convention for finding the view
>controller name associated with a view Id. The view controller name becomes
the
>default "@managed-bean-name" clay symbol.
>
>org.apache.shale.view.ViewControllerMapper
>org.apache.shale.view.faces.FacesConstants
>org.apache.shale.view.impl.DefaultViewControllerMapper
>
Maybe EL would be another way to handle the vew controller mapping
without needing the interfaces. With a value binding expression we
could get to the mapper "#{applicaiton['org$apache$shale$view$VIEW_MAPPER']}".
Then create a method binding expression to invoke "mapViewId(String viewId) ".
That's a good approach to remove the compile time dependency on
shale-core but does that then mean that there is still a runtime
dependency on it? I was hoping to remove shale-core entirely and just
use shale-clay as a standalone view handler. At least until my
appserver supports core.
>I'm not sure what the best approach would be. Ryan, you have been a longtime
>Clay supporter and I'd like it if we could find a solution. Any ideas?
>
The only questionable move would be duplicating the 4 core utility classes.
