I haven't yet had time to look at everything in great detail, so I'll
just start with a few questions/comments.
Is it correct to say that ContentSource is a wicket component that is
decorated by pax-wicket in order to make it into an osgi service? If
so, to me that is easier to understand than saying "packaged with".
Regarding the "Concepts" page:
- AbstractAggregatedSource: this is beautiful! Suddenly it has gone
from being
incomprehensible to being totally clear. Nice!
- Same thing for AbstractContentSource, along with the explanation.
Great!
I really like how you explained this and the
AbstractAggregatedSource, oh
and RootContentAggregator as well.
- Maybe AbstractPageFactory needs some additional explanations...
but then again,
maybe it would be easier just to introduce the concepts in order
of appearance
rather than alphabetical order or whatever. And links between the
definitions
would be useful as well.
- Need more diagrams. Picture's worth a thousand words. :-)
- If ContentId = wicket:id, can't we just get rid of the concept of
ContentId? Why introduce yet another term to learn/remember if it's
not needed? Can't we just call it a WicketId? Makes perfect sense
to me...
- Model vs. Components: this is a very important concept, so
somehow it
needs more explanation.
- I'm still having trouble with "Destination", but I can't put my
finger
on why this is so.
I'm still pondering the rest, but I leave my largest comment for last.
My next comment may be a bit radical with respect to your design, so
I expect you'll show some resistence... But I'm wondering if it's
really necessary to use the "destinationId=aggregationId.contentId"
with a string.
The reason I say this is because ideally, the framework should be as
intuitive as possible. If people want or need to understand the
details, that's fine, but they shouldn't be forced to.
Now, in my mind (so I'm assuming other dimwits think like me), I
associate a string with some kind of nitty-gritty implementation
details. My mind is usually more open to accepting objects than
strings. Not sure why this is so, but it is. Anyway, I naturally
accept that an object is some kind of abstraction of something, so I
don't feel the psychological need to understand all the fine details,
and I can easily accept the concept of the object. When I see a
string, though, my mind gets out of relaxation mode.
With that in mind, couldn't we use some kind of DestinationDescriptor
or something, that has fields that can be set... so maybe something
like:
public interface DestinationDescriptor
{
String getAggretationId();
String getContentId();
}
Ok, so by now you're laughing at me, thinking "not only is that the
same thing, but using an object is more complicated than just using a
simple string!" Maybe so... but like I say, to me it's the
psychological effect that, IMHO, will lower the resistance barrier
when learning pax-wicket.
Also, though I haven't thought about it in detail, maybe it would get
rid of the need to have to understand in too much detail the
ContentMatchExpression and AggregationMatchExpression.
Just a thought.
On Jan 15, 2007, at 19:02, Niclas Hedhman wrote:
>
> Gang,
>
> I have worked quite a bit on documentation, which I would
> appreciate if you
> have a look at; http://www.ops4j.org/projects/pax/wicket
>
> This is not Wiki, but Maven generated stuff and sources sit
> in /repos/ops4j/projects/pax/wicket/src/site if anyone feels like
> editing
> material.
>
>
> Cheers
> Niclas
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
