On Mon, Dec 14, 2009 at 14:39, Vincent Massol <[email protected]> wrote:
>
> On Dec 14, 2009, at 2:31 PM, Thomas Mortagne wrote:
>
>> On Mon, Dec 14, 2009 at 10:10, Vincent Massol <[email protected]>
>> wrote:
>>> Hi,
>>>
>>> Following on the model emails, I'd also like to do the following:
>>>
>>> * Introduce a new Model component to access the Model objects from
>>> the
>>> Execution Context (same as we do for other modules to prevent
>>> everyone
>>> from directly accessing the EC). For now I have:
>>>
>>> /**
>>> * Allows accessing Model Objects for current objects (current
>>> document, current wiki, current space, etc) placed in
>>> * the Execution Context.
>>> *
>>> * @version $Id$
>>> * @since 2.2M1
>>> */
>>> @ComponentRole
>>> public interface Model
>>
>> Wouldn't ModelContext be more clear unless you plan to make Model
>> interface the entry point of the whole model to not get only
>> contextual informations.
>
> I'm not sure about the name indeed. The idea is to do like we do for
> other modules which provide access to information stored in the EC
> (VelocityManager for ex).
>
> Re using Model/ModelContext for other things too, I don't know yet.
>
> I agree that ModelContext would be better for now since FTM I can only
> see its usage to get info from the EC.
>
>>> {
>>> /**
>>> * @return the current document located in the Execution Context
>>> or null if no current document exist
>>> */
>>> DocumentName getCurrentDocumentName();
>>> }
>>>
>>> I'll also like to add getCurrentWikiName() and getCurrentSpaceName()
>>> later on.
>>
>> Why later for getCurrentWikiName() ? It's as important as the current
>> document I think.
>
> Just because we haven't decided yet if we want the wiki name to a
> String or introduce a WikiName class.
Ha yes, i did not though of that.
>
> I'm hesitating:
> - WikiName is nicer (more symmetric with DocumentName and SpaceName,
> allow for changes)
Yes sounds nice.
> - WikiName is a bit harder to use for the user and is overkill if we
> never add anything else than a String property in it. I can't think of
> anything to add right now though.
Sure it's a little overkill but not that much since it returns it, we
don't ask user to create a WikiName to use a method for now ;)
And anyway, according to new model, WikiName should contains some sort
of name for the Server. One future use case for this information is to
be able to query a wiki from another farm using REST form example.
>
> Thanks
> -Vincent
>
>>> * Move *DocumentNameSerializer in Model module (currently in xwiki-
>>> core)
>>> * Move *DocumentNameFactory in Model module (currently in xwiki-core)
>>
>> This will have to be in model sooner or latter so if you are already
>> able to move it now +1
>>
>>>
>>> Here's my +1
>>
>> +1 for the general concept of component getting current model related
>> informations.
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>> PS: FYI here's how I have implemented Model for now:
>>>
>>> /**
>>> * Default implementation bridging to the old XWiki Context to get
>>> current Model Objects.
>>> *
>>> * @version $Id$
>>> * @since 2.2M1
>>> */
>>> @Component
>>> public class DefaultModel implements Model
>>> {
>>> /**
>>> * The Execution Context from which we get the old XWiki Context
>>> from which we get the current Model Objects.
>>> */
>>> @Requirement
>>> private Execution execution;
>>>
>>> /**
>>> * {...@inheritdoc}
>>> * @see org.xwiki.model.Model#getCurrentDocumentName()
>>> */
>>> public DocumentName getCurrentDocumentName()
>>> {
>>> DocumentName result = null;
>>> // TODO: This is bridge to the old XWiki Context since we
>>> currently don't store the current document in the
>>> // new Execution Context yet. Remove when we do so.
>>> try {
>>> Map<Object, Object> xcontext =
>>> (Map<Object, Object>)
>>> this.execution.getContext().getProperty("xwikicontext");
>>> Object currentDocument = xcontext.get("doc");
>>> result = (DocumentName)
>>> currentDocument
>>> .getClass().getMethod("getDocumentName").invoke(currentDocument);
>>> } catch (Exception e) {
>>> // Shouldn't happen in normal cases. Could happen if the
>>> context doesn't contain the old XWiki Context
>>> // but that would be a bug in the initialization system
>>> somewhere.
>>> }
>>> return result;
>>> }
>>> }
>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
