On Mon, Dec 14, 2009 at 14:39, Vincent Massol <vincent(a)massol.net> wrote:
On Dec 14, 2009, at 2:31 PM, Thomas Mortagne wrote:
On Mon, Dec 14, 2009 at 10:10, Vincent Massol
<vincent(a)massol.net>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne