[pmwiki-users] ZAP syntax ideas...

[Hladůvka Jiří]

The Editor napsal(a):
> ...
>
> 2). I'm also thinking of changing the datapage command to target.
> Currently datapage is only used for saving data values (text vars),
> and edit, create, etc. have to have their own mechanism for defining
> which page is to be edited/created. In using a more generic name,
> "target"  could be used for all of these functions and again simplify
> the syntax they use (ie no editbody, etc).
>
>   
Datapage is ok as it is clear I will use data stored in some page. 
Target is used in html
as <a href= ... target=someOtherWindow ...>  and I think in PmWiki core 
is used %target= as well
for the same purpose.
The change could cause missunderstanding.

> ...
>
> 5). ZAP has several custom markups for forms including:
>
> (:zaplink:) Sets up a link that will submit a zap form
> (:zapsubmit:) Sets up a form that will auto submit a zap from
> immediately when the page loads.
> (:zap field=value:) Stores a value as a session value which is
> automatically added to the POST array when the form is submitted.
>
> I'm toying with the idea of changing the markups to more generic type
> markups like:
>
> (:input link:)
> (:input auto:)
> (:input session:)
>
> There's also a zapform and zapend markup. Already the zapend markup
> can be replaced by (:input end:).  The zapform could perhaps be
> changed to (:input form zap:) or some other flag to trigger the zap
> engine, but I'm inclined to leave these two the way they are. I
> conceptually like the idea of sandwiching a ZAP form in between these
> tags.  But the rest perhaps should all be more standard looking input
> types.
>
>   
I strongly prefer if the non-core (recipes) all start with recipe prefix 
like zap, fox, etc.
Then it's clear that not standard (non-core) processing of the 
command/markup will be used.
i.e. if I see (:zapfrorm then I  know the zap syntax is to be used and 
know which RTFM

> ...
>
> 7). It seems to me ZAP's link command (which creates a fully qualified
> URL to a wiki page) could just as easily be replaced by an expression
> markup like
>
> {(link group.name)}
>
> In my own mind at least, I'm becoming a bit more sensitive to what is
> better as a forms command, a markup expression and a page variable.
> And so wanting to get some of these things cleared up if I can
>
>   
The same as above (5).


> 8). There was a suggestion to replace the savedata and erasedata
> commands with simply save and erase.  (Fortunately this would not
> break any existing forms).  These are shorter and more concise, but I
> wonder if there is merit in keeping the data suffix to clarify we are
> saving/erasing text var data, not page content or something else. In
> this case I find the data suffix somewhat helpful.  The same goes for
> the passdata command, which sends data as GET variables... Or perhaps
> it should just be changed to get? Or passget... Yikes!
>
>   
Do not change, PLS
> 9). Speaking of GET vars, ZAP currently has a (:zapget:) directive
> which retrieves all available GET variables and makes them into page
> variables that can be used on a page.  It seems more reasonable to
> replace it with a markup expression
>
> {(get var)}
>
>   
The same as above (5).
> 10). I'm wondering if there is any strong feeling about changing the
> nextpage command to forward, or even redirect. (It controls where the
> browser is forwarded to on form submission). I like nextpage as clear
> and meaningful, but forward or redirect may be a bit more standard for
> some.
>
>   
Forward what? Redirect immediately? If you feel the nextpage is not 
apposite enough
so why not "zapOnSubmitGoto"

Best regards,
Jiri