Juergen Donnerstag wrote:
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.
Thank you for your description. Makes sense now.
-Matej
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
