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. 2. Modify a document reference to make it unique. I believe XWiki applications have to be able to mix implementations of these components.

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

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

Hi devs, Did you implement this feature? I need exactly this functionality, I would like to auto generate the page title based on some fields taken from the application, is this possible? Thank you, Gianluca -- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Changes-to-Page-Creation-needed-f... Sent from the XWiki- Dev mailing list archive at Nabble.com.

On Tue, Apr 24, 2012 at 1:04 AM, Jerome Velociter <[email protected]> wrote:

Hi Gianluca,

Thanks for reviving this thread, I'll take this opportunity to introduce a little module I've been working on for my own use recently, that implements some of the ideas discussed here, and goes even further in terms of flexibility for some aspects.

I've written a page on my site to showcase the beast and start documenting it : http://velociter.fr/different-take-on-page-creation-in-xwiki

The code is here : https://github.com/jvelo/xwiki-platform-pagecreation

It is still a work in progress (for example, the "counter" argument is not implemented yet), but it is mostly functional and I am using it already in production. I'm planning to publish it as an extension at some point, but right now the packaging is not easy as I'm overriding the create.vm template.

Hope this can feed the discussion on page creation in XWiki and maybe be useful to some.

This is very nice and useful, but it doesn't fit the requirements of AppWithinMinutes because you still have a 2-step creation process. Could be mixed with Template Provider though so that the template author can also specify how the page name/title should be generated. Thanks, Marius

Jerome.

On Mon, Apr 23, 2012 at 7:35 PM, intertesto <[email protected]> wrote:

...

Hi devs, Did you implement this feature? I need exactly this functionality, I would like to auto generate the page title based on some fields taken from the application, is this possible?

Thank you, Gianluca

-- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Changes-to-Page-Creation-needed-f... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi devs, I didn't see this thread already ... I recently had to massively implement this kind of things (auto-generate page name at page creation) for the mail archive app. I'd like to share my thoughts, if of any help or interest for you : - this kind of use-case is usually linked to page/object creation (for an application) and not pure wiki page creation. Usually when you want to generate page name, it's because it's a use-case of object/page instanciation for a custom app. In this case you generally won't leave the page naming responsibility to the end-user, but prefer generating it to have something coherent, and to simplify the creation process. - maybe what would be "cool" would be to propose an alternate way of creating wiki pages for this specific use-case. The idea would be to propose an easy way for an app to propose an inline edit sheet for a particular wiki Class. When user clicks on "create" button a pop-up (modal box) is open on this inline edit sheet. As most of the time what you expect is the user entering values in html form fields, you don't really care about providing "save&continue" nor "preview" possibilities. In this case, you would only provide buttons "Create" and "Cancel" and that's fairly enough IMO. - Of course the "modal" pop-up is not mandatory in any way and may seem off-topic, but it's a way to focus on what is expected for the user, and to avoid him noticing what maybe strange things can happen in the browser url. It's also a nice way to get back to opening page fastly. - with this hypothesis you propose something more suitable than fill page name / click create / fill fields / click "save" or "save&continue" while removing the specific issues of "save&continue" and "preview" WDYT ? BR, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Changes-to-Page-Creation-needed-f... Sent from the XWiki- Dev mailing list archive at Nabble.com.

I've just had a look on your screenshots and it exactly fits the same needs I described :) I just have two remarks of possible improvements to your extension : - it would be nice to offer the possibility to use an existing Sheet to display the object creation form. I've got the same limitation in my "spaguetti" own implementation, I recreated the inline form for my PageCreation pages, instead of reusing the existing display Sheets, because I didn't know how to {{include}} this Sheet in inline editing mode. In your concept, you could have a checkbox "Use specific Sheet for display" and a way to enter sheet name, or just use the Sheet associated with "edit" action. You would only generate the inputs for the "special" properties. - I can see only a "Create" button in the creation views, I suppose you plan to add a "Cancel" also ? For your packaging and the overriding of the create.vm and createpageobject.vm, maybe you could provide them as a custom skin ? This custom skin would be used only to overload those 2 .vm files, and you could provide it where needed as a request parameter "?skin=PageCreationSkin" ? Best regards, Jeremie -- View this message in context: http://xwiki.475771.n2.nabble.com/Proposal-Changes-to-Page-Creation-needed-f... Sent from the XWiki- Dev mailing list archive at Nabble.com.