Cart
[Home] [By Thread] [By Date] [Recent Entries]
I read through this again, and am still amazed at how much you seemed to
take liberties to adapt my comments to fit into something you felt you
could argue against. But I decided to take some time to step away from
this for a bit to make sure I could reapproach this will a clear head,
having thought through as many scenarios as I could, that would seem to
warrant a static approach. In fact, a static approach to this problem
is something we are both proposing -- me partially, you completely.
Lets present a simple scenario that is fairly common in the world of blogging, and see if we can come to a compromise: Many of us generate static HTML files when we write our blog entries. In fact, so do I. So I am not one who can suggest this is totally and completely wrong. In my particular case, your comments regarding a file never changing (or rarely any way) are valid -- except when you bring into play the notion that comments and/or trackbacks will cause a rebuild of a page, and depending on the last visit of the visitor to a page, the conditional get request might invoke a need for a partial, or full page sent back in the response stream. If its been recent enough, then we might be able get away with a partial fulfillment and be happy with this. Not exactly a strategy that can be given a whole lot of credit as there is no predictable pattern to ensure a consistant experience. But its not a death knell either. Extending this just a tad, however... if we simply took the time to create a transformation file that contained all of the pre-rended content that never -- or a least rarely -- changes, and then invoke a transformation process that would check if the post source XML file has changed, and if it has not, plop in the cached file fragment into place, and then the same for a comments/trackback section that would, gaining either partial or full acces to the updates, we have now created something that allows for both stratgedies to thrive in the areas they were designed for, We could, of course, make this even more generic, and implement a similar process for things like side bars, and what have you which would allow for one generic transforamtion file for all entry pages that constucted the client side file in small, easy to cache and manage pieces. The result ensures a clean, simple, waste not, want not approach... something it seems we can easily agree with each other as being a good focus for any particular project or project section. I realize I came across QUITE STRONG earlier... there were good reasons for it, but what I should have done is stepped away for an hour and analyzed things before returning to then write -- the above, more than likely, would have been the result if I had. None-the-less, twisting the words of other folks into something that fits the argument instead of arguing the points as originally stated. is just bad policy. That said, so is writing a response to a post after your firecracker fuze has recently been lit. That was my mistake. I hope you can accept my apology. Maybe we can try and bring this discussion into something that seems more like an attempt at an adaptible solution we call can extend from, and subsequently benefit from, instead of tempting Tommie to bring out the "MulberryTech SmackDown CrackDown", something I know she must dread having to deal with when things like this get out of hand... like they did when I entered into the conversation with my flame thrower and bucket of oily rags. :) Not a good combination, nor a good idea all together. Again, my apologies. How can we solve this such that we can all walk away feeling like we have done something positive, instead of something potentially VERY negative to both ourselves and the community? Any ideas? (probably best if I keep my mouth shut for a bit longer and let others chime in :) Jesper Tverskov wrote: Case for client-side/server-side XSLT transformation
|
