I see... It seemed quite easy, implementing the caching. Except that
this can't work for borders and it's very hacky with repeating
listviews. I only bother about these issues because of ajax. So the
current state is that things work (MarkupIDSetter) unless you use
borders. If the caching is somehow implemented I guess I can live with
this untill 2.0 :))
Hmm.. the markup traversing/caching really needs the actual
components. Maybe this could be done just before first rendering? The
components should already be on their places. This way it could be
possible to determine if the component is border or has no markup
associated (ListItem).
Btw. Are you sure that parents in constructor can help this? I mean
for example ListView: The actual list items are created before
rendering, not in the constructor.
-Matej
On 2/12/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> I committed already something similiar, but honestly this is
> none-strategical at best. Paged borders still don't work and users
> which have implemented there own resolvers will have problems as well.
> Only in theory there is a 1:1 match. What we would need are kind of
> reverse resolvers. In aby case, components must be involved in
> resolving it and they are currently not. And I'm not sure it is
> currently the right time to extend the Component API even further. I
> predict/assume/hope the problem will be much easier/more elegant be
> solved with Wicket 2 and the parent being available in the constructor
> and markup association in the constructor.
>
> Juergen
>
> On 2/12/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > Hi, I did try to implement caching of componentTag positions and as a
> > proof of concept it worked quite well.
> >
> >
> >
> >
> > Markup.java:
> >
> > /**
> > * Initialize the index where <head> can be found.
> > */
> > private void initialize()
> > {
> > if (markup != null)
> > {
> > // Initialize the index where <wicket:extend> can
> > be found.
> > for (int i = 0; i < markup.size(); i++)
> > {
> > MarkupElement elem =
> > (MarkupElement)markup.get(i);
> > if (elem instanceof WicketTag)
> > {
> > WicketTag tag = (WicketTag)elem;
> > if ((tag.isHeadTag() == true) &&
> > (tag.getNamespace() != null))
> > {
> > headerIndex = i;
> > break;
> > }
> > }
> > }
> >
> > final String wicketId =
> > ComponentTag.DEFAULT_WICKET_NAMESPACE + ":id";
> > Stack markupElements = new Stack();
> > // The path of the current tag
> > String elementsPath = "";
> > // go through the markup and find elements with
> > wicket:id and put
> > their index
> > // to cache
> > for (int i = 0; i < markup.size(); ++i)
> > {
> > MarkupElement elem = (MarkupElement)
> > markup.get(i);
> > if (elem instanceof ComponentTag)
> > {
> > ComponentTag tag = (ComponentTag)
> > elem;
> >
> > final boolean hasWicketId =
> > tag.getAttributes().containsKey(wicketId);
> >
> > // If open tag, put the path of the
> > current element onto the
> > // stack and adjust the path (walk
> > into the subdirectory)
> > if (tag.isOpen() ||
> > tag.isOpenClose())
> > {
> >
> > markupElements.push(elementsPath);
> > if (hasWicketId)
> > {
> > if
> > (elementsPath.length() > 0)
> > {
> >
> > elementsPath += ":";
> > }
> > elementsPath +=
> > tag.getAttributes().getString(wicketId);
> >
> > indexCache.put(elementsPath, new Integer(i));
> > }
> > }
> > if (tag.isClose() ||
> > tag.isOpenClose())
> > {
> > // return to the parent
> > "directory"
> > elementsPath =
> > (String)markupElements.pop();
> > }
> > }
> > }
> > }
> > }
> >
> > The findComponentIndex just returns the value from cache. Which IMHO
> > is better then traversing the whole markup every time.
> >
> > The problem I couldn't solve is the numbers in component paths
> > (repeaters). Maybe there really should be a rule "no numbers only
> > wicket:id"?
> >
> > Haven't tested this with border yet, I wonder what will go wrong.
> >
> > -Matej
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > Wicket-develop mailing list
> > Wicket-develop@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
