4 Oct
2011
4 Oct
'11
2:50 a.m.
Hi,
2011/10/3 Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
more
"if" in the code to support even more parameters.
> 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
Hi Vincent,
Thanks for the feedback. See my comments below.
On Mon, Oct 3, 2011 at 7:15 PM, Vincent Massol <vincent(a)massol.net> wrote:
>
// Used to make a document name unique (by suffixing an unique
> counter/identifier)
>
DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference
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.
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
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.
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 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>