I think you guys are talking about two different things (Daniel about
parsing regular and form pages, Rob about parsing template pages), but I'm
not even sure about that. Assuming that's the case:
Daniel - most of what you wrote is a little beyond me, but the basic reason
why the parsing of regular pages is done on a primitive,
character-by-character basis, instead of using either the old or the new MW
parser, is that I know almost nothing about how MediaWiki parsing works. It
would be great if SF could use the MW parser directly, or subclass it, but
it's not something I'd easily know how to do. If you want to look into it,
that would be great - I'd definitely be willing to replace any of the
existing parsing code.
Rob - SMW has the new #declare parser function, which addresses those issues
you're talking about - it associates template fields with semantic
properties, without displaying anything on the screen. I don't know whether
it fully works yet, but eventually I want SF to support it, and probably use
it in the templates that 'CreateTemplate' generates.
-Yaron
On Mon, Oct 20, 2008 at 5:57 AM, Rob Challen <[EMAIL PROTECTED]> wrote:
>
> I have run accross similar problems with the template parsing which
> have led me to have to do all the semantic stuff to do with the
> template inside a div hidden from view, and then all the presentation
> layer stuff afterwards, where it doesn't matter if the forms parser
> doesn't find it.
>
> This points in my opinion at a more general problem I've been having
> which is that of vaying presentation of the same information depending
> on presentation context seems unnaturally hard, particularly since the
> semantic value text doesnt seem to be able to handle text containing
> links and therefore only provide a limited ability to access
> information. This does seem to me to be to do with the
> (understandable) conflation of the semantic structure specification
> and presentation layer specification, I'm not sure whether there is a
> good way to address that though.
>
> On Oct 20, 5:32 am, Daniel Friesen <[EMAIL PROTECTED]> wrote:
> > Is there a pressing need to keep support for the old broken parser in
> > new versions of Semantic Forms?
> >
> > I looked over the code that SF uses to read data out of templates, and
> > create the forms... It's quite disturbing, and I have a feeling it's why
> > one of my pages isn't reading data correctly.
> >
> > The whole concept it works on is flawed... (incrementing/decrementing
> > counts of square or curly brackets) it doesn't understand the concept of
> > brackets that aren't part of templates ( }} and } } are considered the
> > same thing, but don't parse the same), and it also doesn't understand
> > curly brackets being dominant over square brackets (ie: {{ template |
> > param = ... [[ }} ]] }} ... is considered by SF to have a param of "
> > ... [[ }} ]] ", but from what I know of the parser (T_T And I know a bit
> > to much about it) it is actually parsed as " ... [[ " with a ]] outside
> > the template.
> >
> > Also, the way brackets are replaced and parsed for the forms is pretty
> > ugly as well.
> >
> > The reason why I ask... is because if we can drop support for the old
> > parser, it may actually be possible to use the parser itself to handle
> > all the form stuff and actually parse everything correctly. (In fact, it
> > should theoretically be possible to do very light modifications to the
> > processing of arguments so that using | and }} won't break a template
> > and instead will be handled in a special way when it's saved and read.
> > In fact, it may be possible to get magic words and parserfunctions
> > (perhaps even variables) working nicely inside of form definitions (ie:
> > ;) using default={{PAGENAME}} ).
> >
> > Oh, on another note, page name= is fairly broken for me. I tried using
> > it on a company wiki and ended up getting errors about methods being
> > called on null for title variables when I tried saving. Just to
> > understand, I was using something like "page
> > name=<Method[Class]>::<Method[Method]>" for some documentation so that I
> > could enter the Class and primary Method name of a method into the
> > inputs, and save it as Class::method, actually I had similar issues when
> > I was using the &Method[Class]= argument to set the default for the
> > Class field when coming from a "Create a new method" link on a Class'
> page.
> >
> > Well, getting back on track. Basically the whole thing to understand is
> > about the new preprocessor. It is what handles all of the curly braces.
> > Parser functions, templates, magic words, and even variables are all
> > built into a tree. In fact it handles all the parsing of named vs.
> > numeric parameters, and variable data.
> > The nice thing is, you can actually use the preprocessor to get a tree
> > from a page, and then parse out information from all the frames in it.
> > ;) ie: extract the actual parameters to a template. On top of that, if
> > you go and subclass the parser instead, you can actually just override a
> > few methods, and end up redefining the meaning of types of curly braces.
> > ^_^ So you could go, subclass the parser, and then redefine expansion of
> > {{{field|...}}} to become a input instead of acting as a variable...
> > Actually, you could even go as far as changing it so that only
> > {{{field|...}}} and {{{standard input|...}}} do that, and then allow
> > special variables to be used. But moreover, you could allow
> > parserfunctions inside of field and input definitions, and even cancel
> > or allow parsing of them. Basically extracting a
> > "default={{#sub:{{PAGENAME}}|0|2}}" and parsing it at the last piece
> > with the actual title, putting a default of the first 2 characters of
> > the pagename as the default.
> >
> > Actually, if you used 2 curly braces instead of 3, it would actually
> > have been possible to just instantiate a new parser, and set a few
> > special parserfunctions on it for handling of form inputs.
> >
> > Actually eventually it would be nice to break a small piece of the
> > freeform forms, out of the forms, and into the #forminput. Basically at
> > least something that allows something like the page name= type setup to
> > work outside of the add forms.
> > ((ie: For my uses, give an input that defines &Method[Method]= and
> > predefine &Method[Class]= on the class page, and then allow someone to
> > enter "hide" into the input on "Anim", prefilling the Class and method
> > inputs with "Anim" and "hide" ending up saving the page as "Anim::hide".
> >
> > Fallback separators or even faux autocomplete (autocomplete by using the
> > separator on the property data) would be interesting for autocomplete as
> > well.
> > ie: Say for my arguments parameter. Say I use a textarea, I set newline
> > as the primary separator, and comma as fallback.
> > That would mean I could enter:
> > type, callback
> > events
> >
> > Into the box. And either use the faux autocomplete, or just save an
> > extra property and autocomplete on that, so that when I go add arguments
> > into another field, it can autocomplete the variables "type",
> > "callback", and "events. I don't care to much if "callback" and
> > "[callback]" are considered differently though.
> >
> > Mmmm... js frameworks... ^_^ Oh right, new job, 3 weeks in... I've got
> > semantics etched into my head (as well as SPARQL and some interesting
> > concepts), I'm writing abstraction to atom queries, and JavaScript has
> > become my favorite language (only subservient to fantasies about writing
> > my own), and I'm writing a small JS framework for use in the project at
> > work, which has provoked me into writing my own JS framework for fun...
> >
> > "foo".has; // undefined
> > "foo".c4$().has('o'); // true
> > with(window.jsframeworks.$4) {
> > $4(block, 'form').event(['click', 'keyup'], ':enabled', function(e)
> > { alert(e.target.value); });
> > String("foo").has('o'); // true
> > var s = new String("foo");
> > s.has('o'); // false
> >
> > }
> >
> > --
> > ~Daniel Friesen (Dantman, Nadir-Seen-Fire)
> > ~Profile/Portfolio:http://nadir-seen-fire.com
> > -The Nadir-Point Group (http://nadir-point.com)
> > --It's Wiki-Tools subgroup (http://wiki-tools.com)
> > --The ElectronicMe project (http://electronic-me.org)
> > -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
> > --Animepedia (http://anime.wikia.com)
> > --Narutopedia (http://naruto.wikia.com)
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Semantic Forms" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---
