> Yes, I know. But I don't know why I need to know the markup in
> constructor. I'm sorry if i'm starting to be annoying, I just know that
> there probably is something I'm missing. I usually need to know the
> markup (attributes of tags specifficaly) only on component render (like
> MarkupIDSetter), not in constructor. But as I said, there probably is
> something I'm missing.
>
It is not annoying at all.
a) Some users over time have expressed the need to access the tag
attributes of the component but also of any tag in the constructor.
Usually in the context of javascript. Reason: you create your modifier
etc in the constructor, ... and I understand users which say that it
simply is more natural to make the decision when you construct it
rather than sometime later (during the render phase).
b) I guess you know that at render time you can not modifiy the
component hierachy any more (which cause some problems and which is
why we have autoAdd())
c) If I'm not mistaken getMarkupId is mainly used during construct
which is why Igor uses getMarkupAttributes() instead of
getMarkup().getAttributes(). This is significantly different: The
latter accesses the markup stream/tag already assigned to the
component where as the first, first tries to find the markup and tag
and retrieves the attributes from there. It is independent from the
current position in the markup.
Juergen
> Other then that, I really like the idea of having parents specified in
> constructors, having worked with foxtoolkit, I know it has advantages.
>
> -Matej
>
> > Juergen
> >> -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?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=k&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&kid=103432&bid=230486&dat=121642
> _______________________________________________
> 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
