The extension mechanism feels dirty to me, because it just sounds like something that could easily be tricked by hacker types, I just can't think of a scenerio where that's true yet.
The ultimate problem I'm initially trying to solve is getting my old friend dojo to work with the asset service. It does async io requests for .js/.css/.html files relative to it's root context on an "as needed" basis. This sort of breaks the current impl because the urls are definitely not handed out by the asset service beforehand. Your idea may be good as well, my brain isn't following the parsing and url rewriting part as easily though. Maybe you are giving me too much credit ;) I definitely don't want to ~hack~ in fixes for my problems though, if this isn't ideal I can stop and re-think. On 12/25/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > I was thinking about this as well. Not protecting certain resources, > by extension, may be a very good solution. It's probably easier to > implement than my idea, which is to parse CSS files and rewrite URLs. > > On 12/25/05, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > I'm writing this message to be sure I haven't misunderstood what the > > intentions of the asset service digestion of url strings were/are before > I > > go breaking them. > > > > From what I can tell the largest need for protection is that of .class > files > > because the asset service exposes the inner classloader resources of the > > running jvm. This makes sense, but the protection of ALL resources this > way > > also hurts some other things. > > > > I'm pondering creating a new hivemind configuration contribution that > > defines what types of resources should be protected. This could go the > other > > way too, where it defines what types of resources ~shouldn't~ be > protected, > > but the first seems easiest. Initially I'm thinking that only resources > > ending in .class file names will be protected. > > > > This also starts the ball rolling on fixing the other issue we have, > which > > is the disconnect between the Shell component's js/css includes and > those > > private assets provided by libraries/components that wish to provide > them. I > > think that components should be able to auto-include their global > resources > > into the Shell component somehow. Not sure how yet. It could either be a > > default that is allowed, additonally allowing hivemind configuration > points > > to exclude or disallow all or specific components/libraries from > > contributing their global assets. This hints at the IAsset class > starting > > to have knowledge of types of resources, or at least a configurable > string > > grouping mechanism. Guess we can figure that one out when we get to it. > > > > jesse > > > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
