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]
