Hi Ludovic,
Thanks for the feedback. I made the proposal thinking that an XWiki
application would follow this steps to automatically generate page
names:
1. Put a Create button on the application home page:
----------8<----------
{{velocity}}
## Safety measure. The temporary document is not saved but someone
could create it manually.
#set($tmpDocName = $xwiki.getUniquePageName($doc.space, 'Temporary'))
#set($tmpDocRef = $services.model.createDocumentReference($doc.wiki,
$doc.space, $tmpDocName))
#set($editParams = 'editor=inline&template=AppCode.Template&parent=App.WebHome')
{{html}}
<span class="buttonwrapper">
<a href="$xwiki.getURL($tmpDocRef, 'edit', $editParams)"
class="button">Create</a>
</span>
{{/html}}
{{/velocity}}
---------->8----------
2. Specify the document reference generator/differentiator in the edit sheet
----------8<----------
<input type="hidden" name="documentReferenceGenerator" value="foo" />
<input type="hidden" name="documentReferenceDifferentiator" value="bar" />
---------->8----------
3. Write custom generator/differentiator in groovy if needed.
And that's it. As you can see, the application doesn't call the
generator/differentiator. They are called by the save action, which
instead of saving the temporary document it saves the document with
the generated reference. The application can configure the
generator/differentiator by
* adding more hidden fields which will be available as request
parameters to the generator/differentiator (this is needed if the
application creates multiple types of documents and it uses different
naming rules for each type)
* using a space-level configuration source (space preferences) that
affects all create forms in that space.
Now, regarding the number of components, one vs. two, I don't think
it's enough to say "I want an unique name". Unless we expose lots of
hints like title, title/realUnique, title/pseudoUnique, field,
field/realUnique, field/pseudoUnique, etc. the application will need
to specify both how the name is generated and how/if the uniqueness is
satisfied. I don't see why a differentiator (even a custom one) would
not work with any generator. To me they serve two different concerns.
Thanks,
Marius
On Tue, Oct 4, 2011 at 3:50 AM, Ludovic Dubost <[email protected]> wrote:
> Hi,
>
> 2011/10/3 Marius Dumitru Florea <[email protected]>
>
>> Hi Vincent,
>>
>> Thanks for the feedback. See my comments below.
>>
>> On Mon, Oct 3, 2011 at 7:15 PM, Vincent Massol <[email protected]> wrote:
>> > 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:
>>
>> The two components I proposed serve two different concerns:
>>
>> 1. Generate a document name from the structured and/or non-structured
>> data of a document. The most simple implementation is to use the
>> document title as the document name but IMO an XWiki application
>> should be able to write its own generator (in groovy for instance).
>> ---> Ludovic and devs writing XWiki applications should confirm if
>> this is really needed.
>>
>>
> Yes we definitively need flexibility. The only way to make sure we don't
> have to get back to scripting the whole creation process is to make sure
> there is extensibility in this creation process.
> Groovy to provide a generator is a great way to do it.
>
>
>> 2. Modify a document reference to make it unique.
>>
>> I believe XWiki applications have to be able to mix implementations of
>> these components.
>>
>>
> I'm not sure it's either good neither viable to have 2 components. I don't
> think you can really transform a document reference to make it unique.
>
> The uniqueness of the document reference is potentially a bummer. Some
> clients have asked for a "real" uniqueness, which can only be implemented
> using a "reservation" system.
> (the issue here is to make sure that between the moment you chose the
> document reference and the moment you actually save the document, nobody has
> been able to get the same document reference)
>
> It is better to do the generate and uniqueness (or pseudo-uniqueness) in the
> same process. The configuration which tells us which generator to use will
> be the one deciding if uniqueness is involved or if it duplicates should
> generate an error (we can need an AJAX API for that by the way, part of the
> validation api).
>
> I also agree with Vincent's object oriented approach and not using "if" in
> the template. I think it would be better to have one API "generate" and if
> this API returns nothing then it means that the generator could not work.
> This is better than testing for parameters, since there can be many use
> cases for generators (which we have not coded) that are valid which might
> not involve the same parameters we check for in the "if".
>
> So we should start with one API and provide a couple behaviors for one or
> more implementations:
>
> 1/ Title (or other fields) to Name transformation with and without
> uniqueness counter
> A couple text transformation could be provided (normal names, wiki style
> names, seo friendly names with authorized/unauthorized special chars)
>
> -> I would put the priority to unauthorized special chars normal names
> and then on seo friendly names
>
> 2/ Pure counter with prefix
> Real unique or Pseudo unique are possible here. Fill or not filling
> holes.
>
> -> I would put the priority to a prefix + pseudo counter
> and then also work on a prefix + real counter with a reservation stored in
> the database valid for a maximum time (5 seconds)
>
> Ludovic
>
>>
>> > 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?
>>
>> You go to the Blog home page and click the Create button which takes you
>> to:
>>
>>
>> /xwiki/bin/edit/Blog/TemporaryBlogPost253?template=Blog.BlogPostTemplate&parent=Blog.WebHome&documentReferenceGenerator=custom
>>
>> If we keep "Save & Continue" then it will be possible to create a new
>> document everytime your click it because the factors that influence
>> the generated document reference can change (e.g. you modify the
>> title). We could keep only "Save & View" but I thought "Create" is
>> better from UX point of view.
>>
>> >
>> >> (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.
>>
>> The idea was to let XWiki applications use the standard edit/create
>> form offered by the XWiki platform. I can drop (2) and let each
>> application add those hidden input fields in their edit sheet if they
>> need to generate the pane name automatically. Regarding (3), the
>> reason I proposed to hide the Save buttons and show Create only when
>> those specific request parameters are set is because I wanted to keep
>> the current behavior for normal wiki pages and existing XWiki
>> applications. My basic need is to distinguish between create and edit
>> form. The simplest solution is to show the Create button instead of
>> Save buttons when the document is new, but that's an important change
>> (for instance lots of functional test will be affected) and I didn't
>> want to make it in 3.2RC1.
>>
>> >
>> > 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 ;)
>>
>> Well, that sounds nice, but Velocity templates are not object oriented
>> and it's not easy for an XWiki application to reuse/customize an
>> existing template without duplicating its code.
>>
>> Thanks,
>> Marius
>>
>> > </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
>> >
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
