Juergen Donnerstag wrote:
On 2/12/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
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?
But that is exactly what is causing the problems. During render
several resolvers (markup to component) are invoked to find the right
component. What getMarkupId etc require is to find the markup for a
component, which exactly the reverse.
Separating the current render phase into a build and render phase is a
lot of work and already on the feature list for 2. Certainly nothing
for 1.2
Okay, I get it :) I can imagine it's not possible to make these changes
to 1.2.
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.
you need the parent to find the markup
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.
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
