On Tuesday 16 January 2007 12:58, David Leangen wrote:
> 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".
Nah. That is incorrect. The ContentSource is the "Build Model" of a Wicket
component hierarchy (any depth). The ContentSource "exists" way before the
Wicket components are trying to be created (hence a 'build model').
More of a "Template", but that is even more confusing IMHO.
> - AbstractAggregatedSource:
> - Same thing for AbstractContentSource
> AbstractAggregatedSource
> and RootContentAggregator
Thanks. It was long discussion and thinking around these, trying to find
the "natural" thing. Not easy.
> - Maybe AbstractPageFactory needs some additional explanations...
Ok. Will try to do that.
> 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.
Well, I think the "concepts" page should be in alphabetical order, but perhaps
have a similar page that introduce it in sequence. More like a user guide. I
want to keep the Concepts as a reference page.
> - Need more diagrams. Picture's worth a thousand words. :-)
Ok. Will work on that.
> - 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
He he he... You suggested that it was hard to understand that Wicket was
shining through, but only very little. I have no problems with WicketId
instead. Edward, what do you think?
> - Model vs. Components: this is a very important concept, so
> somehow it needs more explanation.
Ok.
> - I'm still having trouble with "Destination", but I can't put my
> finger on why this is so.
Possibly because you don't have the view of the ContentSource to be destined
for inclusion somewhere.
> 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.
> public interface DestinationDescriptor
> {
> String getAggretationId();
> String getContentId();
> }
>
> Ok, so by now you're laughing at me, thinking "not only is that the
> same thing,
Not at all. This has been considered over and over, and was the first choice.
But, since the Destination can be set with the Configuration Admin service in
runtime, things suddenly got a lot more complicated, if the suggested
approach was taken.
Since we have come a long way since the first trials in May, it is perhaps
time to re-visit this action item and see what it takes to get the general
Configuration Admin service, and our agents, to support it.
Thanks a lot for the feedback.
Niclas
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
