I just had a thought about RE and the unprotecting, which doesn't make
me very happy.
REs are very tricky, and depending on the code you use,
- say you unportect RE '*css'
- say you don't have $ at the end and don't match the whole expression
- say some one gives along 'org\a.css\..\..\..\WEB-INF\' and so forth...
I know I am very paranoid, but I think it comes from internet reality...
What about taking another strategy and making unprotection on a
'per-resource' strategy, using the xml.
Say we add an attribute to the <asset, called unprotec.
When tapestry processes the XML, the resource will get unprotected, once
(since tap. processes the xml once), for the whole application?
so you define
<asset ... unprotect="yes"/>
this would be better also because it brings the usage (which relies on
unprotection in some cases) and the unprotection itself very close together.
Cheers,
Ron
Jesse Kuhnert 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
