>
> 3 is by far the worst when it comes done to performance. Because we have to
> do it everytime for every request
> even if there isn't a tag like that.. And if it is then we have to
> manipulate (string concatting and copying) the buffer
> And it can only be done when the person does buffer the response...
>
I don't think the performance is that much worse.
i think it will. Because you have to scan really every output everytime for to find if it has to
replace something. And if it has to replace something then it concats and copies
large strings (pages can become easily 25> 100KB)
That generates a lot of garbage
We could optimze it a bit by using our AppendingStringBuffer for manipulation output
So we just alter the internal string array by giving that class replace(String toSearch, String replaceString) methods
then we search for the toSearch string and we alter the internal array with the replace string
Yes we have to do it for all requests, but only than you can change
your properties on the fly. Else you'd have to remove the entry from
the markup cache to force markup reloading.
String manipulation I'd guess is about the same in all 3 scenarios.
Your last point is wrong. Transformers are independent from the
RESPONSE_BUFFER settings.
I wasn't talking about transformers. I was talking about Filters. Filters run
over the complete output of the page after it is rendered.
And if you use a transformer for that over the completel page.. Then that is the same
as the Response_Buffer setting...Because you do buffer then completely.
by the way we really should depricate this:
public abstract CharSequence transform(final Component component, final String output)
and make it:
public abstract CharSequence transform(final Component component, final CharSequence output)
or
public abstract AppendingStringBuffer transform(final Component component, final AppendingStringBuffer output)
Because when no transformation happens then the toString() is a waste
and the transform method can do the alterations in the appendingstringbuffer itself.
> If we store the markup under the locale and the markup is parsed for that
> locale and all resources are inserted into
> the markup. Then it doesn't matter if it is a wicket component tag or not.
> Just set the right attribute value into the
> Component tag attribute. (if a developer alters that again it is his doing)
> Then we only parse once and we have the right markup file per locale.
>
true, see above.
Hot deplyoment of properties files would require clearing the cache
(not true, but everything else seems far to complicated)
yes i agree clear the cache completely. It is most of the time developerment mode only.
I want speed and performance when i am in production.
Ofcourse also then we could have properties comming from a database that should be reflected on a page..
But somehow something must be reloaded then and that can clear the cache.
johan
