Can be such components "marked" - for example by implementing empty
interface (or in by overriding some method (eg. hasMarkup() { return
false; ) ?
saki
> Either components which dynamically create markup, that is what you
> are referring to, but also components which have specific requirements
>
I've just added means to register additional IMarkupFinder with the
application, similar to resolvers. I'll make some tests in the
following week to figure out what the impact realy will be.
Juergen
On 8/22/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> On 8/22/06, Juergen Donnerstag <[EMAIL PR
On 8/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> Not yet, until now I prepared the markup loading process to be better
> prepared for the change. The change we are talking about is not a
> small change. It means to turn the render process inside out and I
> thought that is planned for V3
Either components which dynamically create markup, that is what you
are referring to, but also components which have specific requirements
on where to find/load the markup from (see wicket-examples)
Juergen
On 8/22/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> The component that has the markup
The component that has the markup itself doesn't have to load it in the constructor i guess.Because we don't have to resolve it really.But how do we know that?johan
On 8/22/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
A problem I came across recently: container.newMarkupResourceStream()is call
A problem I came across recently: container.newMarkupResourceStream()
is called to load the markup and overriding it allows users to develop
components with very special needs regarding the source of the markup
stream. As this method is invoked from Component., you can not
rely on any parameter pas
i want to stress out that it is not just for ajax!It is for everything in 2.0. Markup should be there when the component is constructedbecause developers could depend on it now in the constructor and if because of some
parent in the change that couldn't match somehow it suddenly doesn't work everyt
Not yet, until now I prepared the markup loading process to be better
prepared for the change. The change we are talking about is not a
small change. It means to turn the render process inside out and I
thought that is planned for V3. IMO there will be no perfect solution
for V2 which is due in ~2
so whats the deal with the resolvers? you guys come up with something concrete?i was thinking about the repeaters - currently if you look at ICellPopulator the populateItem method looks like this:void populateItem(final Item cellItem, final String componentId, final IModel rowModel);
that component
But we really need to find a solution for that before the final of 2.0Drop the resolver completely or whatever for me we can't support both thingsThen 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 so
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 compon
yeah looking that the IComponentResolvers implementationsThey are not really for resolving markup for a componentBut 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 ha
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 add
What do you mean the current new code (the code now in components constuctor?)is only there for ajax?It has nothing to do with ajax. It has everything to do with fail as early as possible whenadding components to a parent.
The MarkupFinder has to be improved that it uses also the MarkupResolvers so
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 Compon
15 matches
Mail list logo
