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