30 Sep
2008
30 Sep
'08
9:30 a.m.
On Sep 30, 2008, at 9:22 AM, Anca Paula Luca wrote:
Thanks
-Vincent
Vincent Massol wrote:
The main reason for my comment is that the notion of Context and
Contextualizer exists in component based programming and in plexus and
it's something different. For example we could have added a
Contextualizer interface with a single method:
contextualize(ExecutionContext context);
It's not very important but my fear is that readers will use your
example when they write code and would lead to badly named classes.
BTW I see you've used that in Watch components so that should be
modified too IMO.
Very good! :)
Some small comments:
* Not sure why you call the class HelloWorldContextualizer instead of
HelloWorldVelocityContextInitializer
Just for a shorter name and because that component does not actually
initialize
velocity context, it just uses that to get access to the
VelocityContext. So its
semantic is not that of initializing velo context but of
contextualizing the
HelloWorld. Happily enough, this hijack method won't last.
If you think we really must, I can change it. * Might be
good to have a small section about the fact that
components
remove the need for static code (for the best!) since you can have a
component with a "singleton" lifecycle.
Maybe we should have a better section about the <instantiation-
strategy> and
what can be done with it, because eliminating the static code is not
the
components' main benefit and I'd like to keep the tutorial to "what
you really
really need to know" stage, with links for further info. The rest should be for Sergiu's expertise since
he's the one that
contributed
those last three paragraphs.
> * "and since we don't want to add the whole core and all its
> dependencies as a dependency of a simple lightweight component, ".
> Actually the real problem is that this would create a circular
> dependency since the core uses the components.
> * "In the component world, the current request information is held in
> an execution context. This is actually more powerful than the old
> XWiki context, as it is a generic execution context, and you can
> create one anytime you want and use it anyway you want. And you don't
> have to manually pass it around with all method calls, as execution
> contexts are managed by the Execution component, which you can use
> just like any other XWiki component.". We need to specify that it's a
> ThreadLocal implementation (meaning you get a new instance of the
> Execution context per thread). This means also that it's initialized
> by default at all XWiki entry points (i.e. where threads are created:
> Servlet, Portlet, Lucene thread, Stats thread, etc).
> * "If you need some functionality from the old core, consider
> rewriting that part as a new component first, and then use that new
> component from your code.". I'd rather ask to discuss it on the list
> so that we find a solution collaboratively
>
> I even learnt something! Good idea with the old xwikicontext cast
> to a
> Map, hasn't thought of that :)
>
> Excellent work Anca.
>
> Big +1 to link it from our dev practices document.
>
> Thanks
> -Vincent
>
> On Sep 29, 2008, at 8:33 PM, Anca Paula Luca wrote:
>
>> Hi devs,
>>
>> while developing my XWiki watch component, I've written a quick
>> start tutorial
>> on XWiki components, which I would like to add in the dedicated
>> section on
>> platform.xwiki.org.
>>
>> It is currently in draft version at
>> http://dev.xwiki.org/xwiki/bin/view/Drafts/CreatingComponents .
>> Please give it a
>> critical look and signal any errors that might have slipped or send
>> improvement
>> suggestions.
>>
>> Here's my +1 for taking it out of draft version, WDYT?
>>
>> Happy coding,
>> Anca Luca