Drop the resolver completely or whatever for me we can't support both things
Then when using a custom what ever resolver will completely bypase the constructor change..
That just can't be in my eyes.
We should just think about a solution as soon as possible so that all the components
gets on constructor time there markup resolved. Not at render time anymore
So how can we do that.. How would you rewrite the current resolvers we have here in core
(So don't think about custom resolves)
johan
On 8/8/06, Juergen Donnerstag <[EMAIL PROTECTED]
> wrote:
On 8/8/06, Johan Compagner <[EMAIL PROTECTED] > wrote:
> yeah looking that the IComponentResolvers implementations
> They are not really for resolving markup for a component
> But they are much more resolving components (creating them) for the markup.
> And some are really calling render() on components so they really think they
> are in the render phase.
>
> But we have to resolve the markup of the component in the constructor
> Everything just "depends" on that now. We are saying now in 2.0 that you can
> do anything
> in the constructor of your component/panel. That you have everything there
> now (attributes and so on)
>
> We just can't make exceptions there that sometimes that isn't true.. That
> would just be wrong.
The current implementation is already a temporary solution only. I
don't see any issues with changing it until the resolver approach has
been completely removed. Keeping it as is means that some 1.2 code
doesn't work in 2.0. That includes e.g. bordered pages as well as all
apps where users created there own resolvers.
> So we just have to find a way to always be able to resolve the (none
> autoadd) components that are
> added in the constructor..
>
> What kind of situations do fail now?
>
see above. Because users have been allowed to create there own
resolvers, and they did in the past, IMO there is no simple solution.
Eventually they'll have to create a IMarkupFinder for there own
resolvers, but until we changed the core these applications shouldn't
fail all by a sudden.
Juergen
>
> johan
>
>
>
> On 8/8/06, Juergen Donnerstag <[EMAIL PROTECTED] > wrote:
> > On 8/8/06, Johan Compagner < [EMAIL PROTECTED] > wrote:
> > > What do you mean the current new code (the code now in components
> > > constuctor?)
> > > is only there for ajax?
> > >
> >
> > The MarkupFragmentFinder has been developed to support AJAX calls. As
> > it can be used to detected markup errors early, it has been added to
> > the Component constructor.
> >
> > > It has nothing to do with ajax. It has everything to do with fail as
> early
> > > as possible when
> >
> > clearly it has. see above.
> >
> > > adding components to a parent.
> > > The MarkupFinder has to be improved that it uses also the
> MarkupResolvers
> > > somehow.
> >
> > I don't think that it is possible. Resolvers work exactly the reverse
> > order. Resolvers take a wicket:id and find the component in the
> > hierarchy. MarkupFragmentFinder takes the component id and searches
> > for the markup fragment. IMO the idea of the resolvers should find
> > there way into core, but the implementations will be completely
> > different.
> > But that wouldn't solve the problem. The whole render() process is
> > based on the "traditional" approach. We would need to change that as
> > well to eliminate the need for "traditional" approach. Otherwise
> > you'll allways have to maintain two resolvers, one for the
> > "traditional" render process and one for the MarkupFragmentFinder.
> >
> > >
> > > We just have to have 1 perfect way to resolve the markup that belongs to
> a
> > > component.
> >
> > I completely agree, but I don't think it can be done over night.
> >
> > > And that should be called in the constructor of the component.
> > >
> >
> > yes. And until it is available we should replace the exceptions with logs.
> >
> > Juergen
> >
> > > johan
> > >
> > >
> > >
> > > On 8/8/06, Juergen Donnerstag <[EMAIL PROTECTED] > wrote:
> > > >
> > > Since we introduced Ajax we have two different means to associate
> > > Components and Markup. The "traditional" way which resolves the
> > > Component based on the wicket:id, and since this approach didn't work
> > > Ajax where we needed per Component render, the new approach resolves
> > > the Markup based on the Component id. The traditional approach (more
> > > specific the implementation of the approach) in Wicket is far more
> > > flexible and evolved than the new one and is able to handle situations
> > > which the new one can't. That will hopefully change soon, but until
> > > than I propose the following change:
> > >
> > > The current code in Component basically disables all traditional
> > > resolvers which are more sofisticated than the new one, however as
> > > stated above the new approach is only used for AJAX components.
> > > Instead of throwing an exception if the new one doesn't find the
> > > markup, I'd much rather log a warning and go on as usual, as there is
> > > a high potential that the code still works. I had a several such
> > > examples in wicket-examples.
> > >
> > > Any objections?
> > >
> > > Juergen
> > >
> > > Component.java:
> > > public Component(MarkupContainer<?> parent, final String id, final
> > > IModel<T> model)
> > > {
> > > try
> > > {
> > > MarkupStream markupStream = MarkupFragmentFinder.find(this);
> > > ComponentTag tag = markupStream.getTag();
> > > if (tag.hasAttributes ())
> > > {
> > > markupAttributes = new
> CopyOnWriteValueMap(tag.getAttributes());
> > > }
> > > }
> > > catch (MarkupException ex)
> > > {
> > > log.warn("MarkupFragmentFinder was unable to find the markup
> > > associated with Component '"
> > > + id + "'. You will not be able to use the component for
> > > AJAX calls.");
> > > // throw ex;
> > > }
> > > catch (RuntimeException re)
> > > {
> > > log.warn("MarkupFragmentFinder was unable to find the markup
> > > associated with Component '"
> > > + id + "'. You will not be able to use the component for
> > > AJAX calls.");
> > > // throw new WicketRuntimeException("Couldn't
> find
> > > the markup of
> > > the component '" + id
> > > // + "' in parent " + parent.getPageRelativePath (), re);
> > > }
> > > parent.add(this);
> > > }
> > >
> > >
> -------------------------------------------------------------------------
> > > Using Tomcat but need to do more? Need to support web services,
> security?
> > > Get stuff done quickly with pre-integrated technology to make your job
> > > easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> > >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > > _______________________________________________
> > > Wicket-develop mailing list
> > > Wicket-develop@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > Using Tomcat but need to do more? Need to support web services,
> security?
> > > Get stuff done quickly with pre-integrated technology to make your job
> > > easier
> > > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> > >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > >
> > > _______________________________________________
> > > Wicket-develop mailing list
> > > Wicket-develop@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > >
> > >
> > >
> >
> >
> -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Wicket-develop mailing list
> > Wicket-develop@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
