Hi Marius,
Disclaimer: I really haven't had the time to think about this so my comments
below are based after thinking about it for 10 minutes only. IMO this requires
some more brainstorming/thinking.
On Oct 3, 2011, at 5:33 PM, Marius Dumitru Florea wrote:
> Hi devs,
>
> For the upcoming Application Within Minutes I need to enhance the
> XWiki platform with the ability to generate the page name
> automatically when creating a new wiki page. For some applications it
> doesn't make sense to have two creation steps: (1) specify the wiki
> page name (i.e. the location) and then (2) edit the new wiki page with
> the specified name. Let me give you two examples:
>
> * It would be cool to be able to create a new blog post in a single
> step. The blog post name could be generated from the blog post title
> specified in the edit form.
>
> * An application that manages holiday requests doesn't need meaningful
> page names (i.e. free text, like a blog post would have) but something
> like Request_XYZ, where XYZ is a unique counter/identifier.
>
> These applications should be able to create new wiki pages with
> automatically generated names without writing their custom create
> forms.
>
> Since 3.2RC1 was planed for today and these changes are in the 3.2
> roadmap, here's a proposal that I think I can implement quickly and
> safely:
>
> (1) Introduce two new components:
>
> // Used to generate a document name that doesn't have to be unique
> (e.g. by cleaning the document title).
> DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference
>
> // Used to make a document name unique (by suffixing an unique
> counter/identifier)
> DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference
I don't see the need for 2 components. I do see the need for one component:
DocumentReferenceGenerator#generate(String prefix)
Then you could have one implementation of it that that takes the prefix and
appends a number to make it unique.
Now for using the title as the reference name, we don't need anything:
new DocumentReference(wiki, space, doc.getTitle());
> (2) Modify editinline.vm to store "documentReferenceGenerator" and
> "documentReferenceDifferentiator" request parameters in two hidden
> input fields so that they are passed to the save action. Obviously,
> these are component hints.
>
> (3) Modify editactions.vm to replace "Save & View" + "Save & Continue"
> with "Create" when "documentReferenceGenerator" or
> "documentReferenceDifferentiator" (or both) request parameters are
> set.
I don't see how what use case (3) solves. Can you explain?
> (4) Modify SaveAction to take into account these two request
> parameters (only if they are specified). Something along these lines:
>
> generateDocumentReference(doc)
> synchronize(lock) {
> doc.copyDocument(differentiate(generatedDocumentReference)).save();
> }
>
> I'm not sure where to place the two components from (1) though. WDYT?
The component I mentioned above could go in xwiki-platform-model.
<general remarks>
Now I'm not very comfortable with hacking the default vm files to add more "if"
in the code to support even more parameters.
Why not use the new sheet system you've started putting in place to specify a
specific vm to use?
More generally I'd like that we think about removing big spaghettis code for vm
and be able to have more vms and that we can choose which vm to use where.
Also, as usual, I'd like to that someone who wants to build on the xwiki dev
platform be able to not use this if he doesn't need to (hence my comment above
about being able to selectively choose what behavior to have/use instead of
having lots of "if"s in vm files. Especially since this new behavior doesn't
seem to be good for the majority of use cases but only for some.
Said differently use an Object-oriented approach or a component-based approach
instead of a big-ball-of-mud approach ;)
</general remarks>
Note that as always, I'd prefer if we do this:
- discuss how we would like it to be in the near future
- then only discuss how to reach that based on constraints (release contraint,
etc) and see how many steps we need to get there
Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
