Thanks. Will chew on this some more.
If I can make time, I'll write more stuff directly into the docs.
Thanks again for all this!
Dave
On Jan 17, 2007, at 15:16, Niclas Hedhman wrote:
> 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
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
