[pmwiki-users] ZAP syntax ideas...

[J. Meijer]

Dan, these are lots of individual points. Given what zap conceptually does (as I understand it), namely provide basic onpost event handling, and given that you are moving towards using conditionals, maybe you should allow a multiline format. Now is a good time to give the matter some thought. 

You now have the format (:zap cmd="parameters":), it could be extended to accept sequences, like (:zap cmd1="params" cmd2="params" etc:), but for one this doesn't seem to work well for if statements. 

It could be an option to instead hike the pmwiki syntax (and mark-up processor) and have it process the formdata. Zap would use it to render a special page/zapscript that contains the required markup and the result would be a text consisting of simple text with embedded (simple) zap-commands. Which would get executed (in what would be an  output phase) by zap. Zap would not attempt to do it all. 

Alternatively you could go to a {(markup expression)} (or similar multi-line) format, which would only be rendered (applied) in the onpost event handler (=zap). This may have the advantage that functions can have the familiar function(param1,param2) format. 

If you stick with a single line for each (:zap cmd="params":), I suggested you change the syntax to the pmwiki compatible (:zapcmd param1=value param2=value2:). This is programatically easy to do, allows named parameters and continues to allow unnamed sequences. Such a step would help documentation VERY MUCH. Things then basically auto-document themselves. 

Now onto your specific points. Please correct me if I misunderstood zap. 



________________________________
> On 4/24/07, The Editor <editor at fast.st> wrote:
> Though I've pretty much frozen ZAP on new features, my work on an
> alternate wiki engine (experimental) has forced me to rethink how a
> few things are done with ZAP in PmWiki.  It's also suggested some
> other ideas unrelated to ZAP.  Thought I would post the ideas here for
> input.

> 1). Currently ZAP has a create command and an edit command. The create
> command creates new pages, the edit commands can do the same but also
> insert sections (like Fox) and insert individual lines (like ADL).  I
> was thinking I should perhaps delete the create command (as it is
> duplicate functionality), and perhaps subdivide the edit command into
> three
> edit: pages
> insert: for anchored section insertions
> log: for individual line insertions
> I would need to rework this section of the ZAP code, but in the
> process it should (hopefully) make things a lot clearer. And also
> simpler codewise--as the edit command has to be very smart to handle
> all the possible options, flags, parameters, properly. And I could
> make some things more automatic--ie easier for the form creator.


On the zapsite you use these life-forms:
  (:zap create="":)
  (:zap create="Demo-Old.1,Demo-Old.2,Demo-Old.3,Demo-Old.4,Demo-Old.5" create:)

What do they do? My intuition doesn't explain it all. What templates does it use or how do I specify templates? 



> 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). 

On the zapsite you have the following life-forms:

(:zap datapage="Demo-Forum.#" forum:)
(:zap datapage="Profiles.{$newmember}":)

Zap manipulates a current datapage which has a default name (-data suffix?), so this 'command' I guess instructs it to use another page instead. 


If your zapscript would be a template, you could write 

  (:zap membership datapage="Profiles.{$newmember}":)

instead (to invoke the membership script and apply it to the datapage). 

Seems like this (zapscripts =templates) would be a nice addition. 




> 3). Currently there is a code command in ZAP which encodes all listed
> fields using an internal coding mechanism. It works great for things
> like passwords and emails, and can be readily decoded (reasonably
> safely) by an admin or an individual user. I'm thinking about changing
> this to encode, and add a decode command. This would make it easier to
> allow things like emailing password reminders, etc.

This would never be really secure (as noted earlier on the list): knowing zap is in use, one can easily decode the encrypted values? So a decode would be no problem I guess... things are already out in the open..




> 4). There is a very nice email_list command which allows you to send
> emails to a CSV list of members (Bob,Dave,Mary,Kate). This is opposed
> to an email_news command which allows you to send to a list of actual
> email addresses.  I'm thinking of changing this to an email_group
> command which could be combined with a nice group management system
> based on pages like Group.Webmasters or Group.ChessClub. It would be
> very easy to add/delete members in ZAP, set up ingroup conditionals,
> group count markup expressions, and more. I'm not sure it can be
> integrated into PmWiki's group authorization system, but that would be
> great if it could. 

Would be nice, of course. It would remove duplicate content: a big headache. 



> 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.

Ben commented on this. Don't know if I understood his suggestion of (:zapform method=auto:), because (:input auto:) would also provide a link/button to trigger posting, and therefore would still be needed. 



> 6). Now for a nonZAP suggestion...  I'm wondering if there can't be a
> markup for nested tables using indents to determine embedded tables.
> For example
> (:table:)
> (:cellnr:)
> (:cell:)
>   (:table:)
>   (:cellnr:)
>   (:cell:)
>   (:cell:)
>   (:tableend:)
> (:cell:)
> (:cellnr:)
> (:cell:)
> (:cell:)
> (:tableend:)

Turning the table on someone? ;) 



> 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

If I understand the command and zap correctly, then yes, this has little to do with zap. It's just in the same namespace as zap, that's why it shares the syntax? But any syntax would do. 




> 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!

This would make sense in a (:zapsave field=Field1,Field2,etc :) syntax (note: no need for apostrophes). 

As a sidenote, this command should not be necessary for most forms, as they'll simple save *all* data (and zap would have to default to that). This suggest an alternate format:

  (:zapsave field=-HaveNoIdea:)

This would store all form-fields except field HaveNoIdea. 





> 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 handling of get/post/session/etc vars will undoubtedly soon be defined within pmwiki. Note: I think the HttpVariables recipy goes about it in the wrong way. Names are also good icons. 



> 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. 

Seems perfectly comfortable to me. But you might use a trail instead.. 




> 11). Perhaps the coolest thing I've done on my experimental wiki is to
> use ZAP forms for actions.  So for example:
> index.php?n=Group.Name&action=edit
> Will display the Action.Edit page with all the page variables from
> Group.Name available in setting up the page (retrieving page content,
> etc). Kind of like Site.AuthForm does. So to create a new action you
> just create a new ZAP form, as simple or as complex as you like.
> I'm wondering if this couldn't be done in PmWiki by doing something
> like the following:
> pmwiki.php?n=Group.Name?action=zap&zap=edit
> The only thing is I'm not sure of is how to overwrite the displayed
> page with Zap.Edit while maintaining the page variables for
> Group.Name. It might be something simple. If so, it could really be
> powerful...

Seems a desirable feature, but what actions do you envision and can they be setup the way you suggest (case in point: action=editform)?  






> 12). A namespace conflict recently came up with ZAP involving it's
> ability to use input fields like email_1, email_2, email_3 to trigger
> instances of the email command multiple times.  Actually, any value
> can follow the underscore.  I'm wondering if it should be limited to
> numbers only, or leave it wide open to allow admins to use any kind of
> flag to identify each instance.  For example email_thankyou,
> email_tech, email_admin (this would only be useful if each email
> message was different in content).

I haven't followed the discussion, why can't I simply write the email command three times with different parameters?? I'm sure zap could add the 1, 2 or 3 automatically if it wanted to. 


> Anyway,
> My goal is to have ZAP frozen in concrete by around the time PmWiki
> comes out of beta, so I'm making a very thorough analysis of all
> things ZAP.  Your input is VERY welcome...

Dan, maybe I best compare zap to assembler or procedural programming: it'll do everything and it's fast, but it puts a lot of the burden on the programmer. 
As you acknowledge, by seperating things zap does into markup expressions and pagevariables, the core of what zap really is becomes more visible. 

Whatever you do, conform more to pmwiki standards: you'll better attend its public, but I'm sure you'll also gain flexibility. 

It may still be a long way to a truely final version. 



I hope you stay on board (sure you will :). No harm is done experimenting with your own wiki. But it's a time-sink. I'm sure your achievements will come back to enrich pmwiki. 

So Neo heard her say, when he broke the vase: you have the gift. But. You already know what I'm going to say: Don't worry. I'll get one my kids to fix it. Here, have a cookie. 



> Cheers,
> Dan


Goodluck! 

/jm










ps Now an unsollicted and undesirable message from the sponsor: 
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE