Menu
▾
▴
Re: [SMW-devel] Automatic-page-creation from Forms
|
From: Rolf L. [RIL] <rol...@ri...> - 2009-01-26 14:49:12
|
Step 2 and 3, they are identical, except for creating two different
classes. What's happening in the underlaying #createpage function is the
same in both cases, namely:
#1. Create the page (and insert the "class" template as usual)
#2. Assign the properties sent as parameters.
Regards,
// Rolf Lampa
Yaron Koren skrev:
> Hi,
>
> I don't understand - of the three page types, which one(s) are getting
> created automatically?
>
> -Yaron
>
> On Mon, Jan 26, 2009 at 9:02 AM, Rolf Lampa [RIL]
> <rol...@ri... <mailto:rol...@ri...>> wrote:
>
> Hi,
>
> Since a n..n relation essentially is made out of two 1..n
> relations (seen from the "middle class") pointing at two end
> classes, and a 1..n relation shouldn't be impossible to fix (see
> the rest of the post below) don't you think your Semantic Form
> could simply implement what Dan suggested, namely 1..n relations?
>
> If a user wants to make a n..n relation he only has to define it
> in two steps instead of one, like so (I'll describe this in three
> different levels of detail below, first the simplest form):
>
> #1. Standard Form:Book definitions.
> #2. A "createpage variant" of a subform for Author (if not exist)
> #3. A "createpage variant" of a subform for BookAuthorLink (if not
> exist)
>
> Press submit and voila!, a page triple is created/assined! :)
> Note that the steps 2 and 3 above are actually identical, they
> only deal with two different objects (pages). Note also that 1..1
> relations as well as 1..n should be possible by implication (due
> to the ability to assign a property in the newly created page/object).
>
> Below the three steps above again, but now in more detail:
>
> #1. Form definitions for a book as usual. only make sure that the
> title is somehow stored in a parameter or variable, since it will
> be needed for linking to the (this) book from the autocreated
> pages lower down on this form.
>
> {{#vardefine: BookTitle | from field name, template or form-info's
> formula }}
>
> #2. Create an Author, no links assigned.
>
> {{{createpage|Author|page title={{{First name}}} {{{Last name}}}
> | First Name=Yaron
> | Last Name=Koren
> }}}
>
> After this Form row has been executed the situation should look like
> this:
>
> [Book] [Author]
> The pages objects are left unlinked, the Title and the properties
> First name and Last name are assigned though, and thus the page is a
> "valid" object on it's own, even if the final linking to the book
> would fail or wouldn't happen due to the main form (the Book) were
> canceled.
>
> #3. At last, create the link object (page) and assign the two 1..n
> links:
>
> {{{createpage|BookAuthorLink
> | role1={{#var: BookTitle}}
> | role2={{{First name}}} {{{Last name}}}
> }}}
>
> Now the situation should be this (in UML representation):
>
> [Book]<-1-role1--*-[BookAuthorLink]-*--role2-1->[Author]
>
> (I would of course name the link properties to Book and Author
> respectively, because when later #asking if the link what's in the
> other end the semantics of names like "role1" and "role2" doesn't
> say what the role1 end page and role2 end page really is.
>
> Moreover, since the page title of the linking page (object) needs
> to be unique it could be autogenerated based on a "ClassName
> (Subject-Object)" formula, that is, in this example the title of
> the BookAuthorLink would end up being:
>
> "BookAuthorLink (How to define n..n relations-Yaron Koren)"
>
> If the creating of pages and assigning of properties is done via
> templates (which I strongly suggest) then the definitions above on
> the Form:Book could like something like this:
>
> Form:Book
> ------------------------------------------------
>
> /**
> * Step 1:
> *
> * Class Book, "main form"
> */
>
> {{{for template|Book}}}
> {| class="formtable"
> ! Book title:
> | {{{field|Book title|mandatory}}}
> |-
> ! Sub title:
> | {{{field|Sub title}}}
> |-
> ! Edition:
> | {{{field|Edition}}}
> |}
> {{{end template}}}
>
> /**
> * Step 2:
> *
> * Class Author, "sub form", auto created (if not
> * exist, in any case the variable for the final
> * title is set.
> *
> * If we can get back the final title of the new
> * page as a return value from the createpage func-
> * tion, it can be used in later stages below. See
> * below how "{{{info|" returns the new title:
> */
>
> {{#vardefine: AuthorName
> | {{{info|*createpage*|page name=/<Author/[/First name]>
> //<Author/[/Last name/]> (<unique number>)}}}
> }}
> {{{for template|Author}}}
> {| class="formtable"
> ! First name:
> | {{{field|First name|mandatory}}}
> |-
> ! Last name:
> | {{{field|Last name}}}
> |}
> {{{end template}}}
>
> Given that all properties of the involved forms up till this row
> are parsed and assigned to variables and named parameters, (thus
> all involved page titles are available to the code below):
>
> /**
> * Step 3:
> *
> * Class BookAuthorLink
> *
> * Links together the Book (this page) and the newly
> * created (or the retrieved title of the) Author.
> * This form need not be visible at all, and so it
> * could possibly use a template directly (?).
> */
>
> {{{info|*createpage*|page name=/BookAuthorLink ({{{Book title}}}/
> /{{#var:AuthorName}}) /}}}
> {{{for template|BookAuthorLink}}}
> {{{field|Role1={{{BookTitle}}}|mandatory}}}
> {{{field|Role2={{{AuthorName}}}|mandatory}}}
> {{{end template}}}
>
> or a direct call to a independent #createpage ParserFunction
> capable of assigning property values:
>
> {{#createpage:BookAuthorLink
> | Role1={{{BookTitle}}}
> | Role2={{{AuthorName}}}
> }}
>
>
> An option for the #createpage call would be whether its allowed to
> modify any properties if the page already exists (default = nope).
> A first approach wouldn't have to bother about determining
> conflicts at all. It would be good enough if the form were capable
> of actually creating the Author object (or retrieving if it
> already exists) when the user presses Submit for that particular
> SUBFORM (as opposed to submitting the main form), and so the user
> would have the chance to know whether he's about to overwrite
> something he didn't intend to modify.
>
> One point with this example is the if one manages to define how to
> automagically create a 1..n relation, then it's not more difficult
> to define a n..n relation either, it only takes defining yet
> another such 1..n relation.
>
> What do you think Yaron? Shall I implement this notation in the
> SmwModeler generator now already (tonight) or should I wait until
> you confirm how you prefer to implement this? ... :) <ducking>
>
> Regards,
>
> // Rolf Lampa
>
>
>
>
> Yaron Koren wrote:
>
> Hi,
>
> Thanks for that full explanation. I think you've confirmed
> what I had previously suspected, which is that any solution to
> creating automatic "linker" pages would be too involved and
> complex to implement, given that it would be just an interim
> solution until true n-ary relations are supported; the benefit
> wouldn't outweigh the complexity. But it's good to know that
> for sure.
>
> Dan - your example is relatively simple and straightforward;
> however, I think it's outside the scope of this discussion,
> since it covers the case of two page types, and what's being
> discussed is having three page types, with one being a linker
> between the other two.
>
> -Yaron
>
>
> On Sat, Jan 24, 2009 at 10:52 AM, Rolf Lampa [RIL]
> <rol...@ri... <mailto:rol...@ri...>
> <mailto:rol...@ri... <mailto:rol...@ri...>>>
> wrote:
>
>
> Regarding the typical "constraint approach" of UML (I'm
> thinking
> especially about the 1..n relation) I'm sensing an emerging
> clash
> between open and closed semantic paradigms here... :)
>
> Would be interesting with some philosophical reflexions
> over this
> possible clash of paradigm from experts on semantic theory.
>
> // Rolf Lampa
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Semediawiki-devel mailing list
> Sem...@li...
> <mailto:Sem...@li...>
> <mailto:Sem...@li...
> <mailto:Sem...@li...>>
>
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
|