[pmwiki-users] new zap release...

[DaveG]

The Editor wrote:
> On 12/21/06, DaveG <pmwiki at solidgone.com> wrote:
>> Some problems on the site:
>>  - Some areas of the site still require login. Snipets in particular,
>> also Documentation.
> 
> I don't think this is correct.  I've checked and doublechecked.  Can't
> find anything still requiring logins...  Did you perhaps double click
> on a link?  If so--that calls up the edit window.  Maybe I should
> change that.  It's just very convenient....
> 
>>  - I actually can't login with Guest/test, nor can I register.
> 
> My mistake.  I upgraded the Register Snippet, but not the live
> Register form.  It should be working now.  Also, somehow the password
> was somehow delete on the Guest account.  It should be working again,
> with that account a bit better locked down.
Fixed.

>> I'm trying to get some basics working with Zap:
>>  - Getting a bunch of "Warning: Invalid argument supplied for foreach()
>> in C:\temp\pmwiki-2.2.0-beta17\cookbook\zap.php on line 103" errors on a
>> basic PmWiki install, only cookbook is Zap. Looks like this may be a
>> known issue.
> 
> No this is a new error--had to do with the part of the code that
> checks for other enabled modules. Only occurs when no other modules
> are installed.  Is now fixed and the updated download is up.
Fixed.

>>  - What I'm most struggling with is displaying data stored on another
>> page. How are those variables referenced?
> 
> You refer to them as any other text variable.  That is
> 
> {$:field} or
> {Group/Name$:field}
Okay. Syntax seems a little inconsistent though, since variables on the 
same page are referenced:
   {$field}


> 
> Text variables can be referenced in a pagelist like this:
> 
> {=$:field}
Still not clear how to reference fields from within a pagelist, when the 
data is stored outside of the page on which the pagelist is being used. 
It appears that the pagelist now need to reference the datapage 
directly, which would make the pagelist less flexible.


>>  - It appears that you wouldn't store multiple records with the same
>> field names in a single page. Thus, lists would be constructed by
>> storing 'records' in separate pages, and displaying the records in list
>> format via pagelist. Is that correct?
> 
> That's right, normally each 'record' would be a different page in a
> group.  Then use a pagelist limited to that group, with whatever
> criteria you want, and it can pull up a table or 'report' of any kind.
> 
>> Some suggestions:
>>  - provide basic examples.
>>    - Show how to display data from another page.
>>    - Point out somewhere early on that Zap relies heavily on pagelists,
>> and provide some examples.
>>
>>  - I remember seeing a quote: "pages can be treated like db records,
>> with individual fields in them". If this is true, it helped put things
>> into context, and should be on the site.
> 
> These are some good suggestions. I've added quite a bit of
> documentation already.  But I could add a tutorial on retrieving and
> displaying data.  If you have other suggestions for improving the
> documentation, let me know.  
Try to make the tutorials flow a little better, leading the reader from 
one real use to another. As they stand I got to the end of the 
tutorials, and really didn't have much more of an understanding than 
when I started. I'd presume people want to store and display data, so 
start the tutorial in that fashion.

> I tried to update it all for the new zap
> but some things may still be unclear.  There's a lot of information
> there to update...  (Took more time than updating the code!)
> 
>>  - Context is important. Fox is very simple to understand as it sticks
>> with data and display templates for displaying data. Zap's concepts are
>> not well defined in the docs.
> 
> Fox is simpler, because it does one thing well, (Hans always does good
> work!)  Basically, it inserts templated page content (either append or
> prepend) into another page.  The reason zap is more complex, is it is
> a toolbox with building blocks you have to assemble yourself.
> (Actually, it has been able to do the equivalent of Fox back from when
> it was still FASTdata--I called it logging, but never used it much as
> I prefer a data-driven approach).
> 
> In my opinion, there are only two reasons one would want to use zap:
> 
> 1) if it happens to have some specific feature you can't find a ready
> made tool for.  If there is a specific tool--use it. If not, hopefully
> zap has a snippet you can just cut and paste.
> 
> 2) if you want a rapid development IDE.  Once you learn how zap works
> you can create very complex applications quickly. There's a learning
> curve--but once you get the hang of it, you do a LOT without ever
> having to touch php. Just hobble together a form. If you do a lot of
> custom coding, learning zap could save you much time in the future.
My point here was not to contrast Fox with Zap, but to highlight the 
fact that it's easy to contextualize Fox. "Here's the data, and here's 
how to display the data". The existing Zap docs don't help the reader 
put anything into context.


> 
> Hope this helps!
> 
> Cheers,
> Dan
>