I think asset externalization is still a good thing to keep. At the
very least, it will be useful if Tapestry ever has static generation
capability.
But in terms of security, even with the mechanism in place to require
the asset hash, I don't like the idea of a general service serving up
general content from the application server.
Congrats on getting the 304 response implemented - that is a big perk!
Erik
On Jul 8, 2005, at 1:53 PM, Howard Lewis Ship wrote:
FYI: I have a fix for the asset service ready to go; I'll be able to
check it in later tonight.
Works like a charm; far fewer requests from the client, since assets
are sent just once.
We set the Last-Modified and Expires headers, and send an 304
response for any request with an If-Modified-Since header. I think
this will mean great things for Tapestry scalability.
In fact, it may be time to remove asset externalization! With
friendly URLs to reference assets, and smart handling of assets as
above, the need for externalized assets is diminished. Externalized
assets have always had problems in a cluster: if server A
externalizes asset Q and server B receives the asset request from the
client, then client gets a 404 (unless all the servers share a
directory somehow). Getting rid of asset externalization reduces this
to a "perfect" solution with zero configuration.
On 7/8/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
On 7/7/05, Paul Ferraro <[EMAIL PROTECTED]> wrote:
It looks like when you split the old validators into pieces (e.g.
StringValidator -> MinLength, MaxLength), you removed the logic that
adds the appropriate script reference to the page. Was it you
intention
to relocate this logic?
Actually, I think this logic should move to either
IValidationDelegate
or to PageRenderSupport. I've been picturing a method like:
public void positionCursor(String clientId, int priority)
where priority is:
0 - normal field
1 - required field
2 - field in error
Probably easiest to put this in IValidationDelegate, and add a
property to delegate to control whether field positioning is enabled
or disabled (there's a Jira issue about that).
Possilbly, this method could also appear on ValidatableFieldSupport,
which would delegate to the IValidationDelegate (the validators see
VFS, not IVD).
I also think we should modularize the js files so that there is a
1-1
relationship (e.g. StringValidator.js -> MinLength.js,
MaxLength.js).
Thoughts?
Can't see this as a real problem. I do want to look at the asset
service to see if we can send a proper response code if the client
already has the file. That is, if the client reports that it has the
file with any non-null date stamp, it has the right file (any change
to the file will change its md5 checksum and therefore its URI)
and we
can send
Here we go ...
Not Modified 304
If the client has done a conditional GET and access is allowed, but
the document has not been modified since the date and time specified
in If-Modified-Since field, the server responds with a 304 status
code
and does not send the document body to the client.
Response headers are as if the client had sent a HEAD request, but
limited to only those headers which make sense in this context. This
means only headers that are relevant to cache managers and which may
have changed independently of the document's Last-Modified date.
Examples include Date , Server and Expires .
The purpose of this feature is to allow efficient updates of local
cache information (including relevant metainformation) without
requiring the overhead of multiple HTTP requests (e.g. a HEAD
followed
by a GET) and minimizing the transmittal of information already known
by the requesting client (usually a caching proxy).
Paul
--
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
n
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
