[pmwiki-users] More cool ZAP snippets up...

[Crisses]

On Oct 23, 2006, at 4:31 PM, The Editor wrote:

> On 10/23/06, Crisses <crisses at kinhost.org> wrote:
>> On Oct 23, 2006, at 2:16 PM, The Editor wrote:
>>
>>> I plan on putting some more advanced features up a bit later when I
>>> have some time, such as instant messaging, chat/shoutbox, intrasite
>>> mail, email lists, classfieds, member blogs, etc.  But I want to get
>>> my own site more zapified first!
>>
>> Thanks for all the work.
>>
>> I don't necessarily understand everything that you're doing, since
>> they're usually snippets devoid of real-life applications, but if I
>> go with ZAP in an upcoming project, you'll probably get sick of me
>> asking you for ideas on how to create forms.  And yes, it will
>> probably be a great test of actual applications for it.
>
> No problem.  I'll do my best to help as far as I can.  It's these kind
> of real life applications that test our limits and stretch our skills,
> knowledge and experience.  I'm really looking forward to working with
> you on this as an excellent opportunity for ZAP to shine.

I agree.

> The real difference between ZAP and FAST Data is a new way of thinking
> about data.  Maybe something along the lines of what XML is supposed
> to do.  That is: organizing all your information into fields, and then
> separating that from the display.  It makes instantly updating the
> layout of every classified ad instantly possible.  Way better than
> static comment boxes.

Yes.  I know that static data isn't the right way to go on classifieds.

I would need to have a way for only the user & the admin(s) to be  
able to change the data, for example, but not any other user(s).

>> I will probably be taking on a classified ads site with a myriad
>> number of features -- including paid subscriptions (probably PayPal's
>> subscription feature) that have to be integrated into the login
>> system (I will refine AuthUserDBase for this), pages &/or ad listings
>> that expire, web guests not being able to see things (that's easy in
>> PmWiki), and a distance-from-zipcode recipe (sorry to non-US
>> people!!  that won't work for you).
>
> I'd recommend a dbase approach for anything using money.

I am in the States and plan on pushing the client to use PayPal.   
There's good reason for it -- I don't like the liability of dealing  
with payment information, for example.  Also, merchant processing  
accounts are generally expensive.  PayPal hits you harder per- 
transaction, but if you have only 5 transactions a month, or each  
transaction is for a low amount of money, it's probably more cost  
effective than the merchant processing account.

>   I've worked
> hard on ZAP's security, but I'm sure there are vulnerabilities I've
> not though of yet.

I have the same problem with things I write.  Planning a shopping  
cart module is going to be a huge challenge, so I am considering  
starting out with the PayPal interfaces.  PayPal handles everything  
that one could possibly panic about security on -- so I don't have  
to.  Later, though, I'm going to have to address e-commerce security  
issues.

>   Particularly with text variables making everything
> so accessible.  ZAP *will* make it very easy for users to create ads
> and display/sort them how you want.  I think by using timestamps you
> can probably limit those displayed to those within a certain realm
> (might need some script to clean up old entries though if you want
> to...).  You'll probably have to do the zipcode thing as that is out
> of ZAP's realm.

I'm definitely not as worried about the ads expiring as I am about  
other portions of the application.  But I'm not going to panic until  
I am actually under contract.
I have found zip-code range applications on the web.  Even Zend has  
an example.  So I'm less worried about the back-end actually- 
calculating-distance portion -- I'm a little more worried about  
storing the user's zip code, the ad zip code, and getting the data  
from PmWiki to the back-end script.  I can think of some ways to go  
about it.  I wasn't expecting ZAP to calculate distances -- I am  
expecting ZAP to store zip code info, so it can be the default in the  
user's search fields.

>> I've looked at other classified ad applications, and plug-ins for
>> large CMS applications, but I don't feel like doing a whole lot of
>> custom programming for other packages when I can do custom work just
>> fine under PmWiki, and probably take less time.
>>
>> And that probably makes PmWiki enter the "hey, this really is a CMS,
>> I guess" territory -- though I guess other people may have gone
>> there.  I'd have to say that with similepedia I've definitely crossed
>> the line from wiki-as-a-light-cms to wiki-IS-a-light-cms.
>
> My FAST site is definitely all CMS, and much more powerful and
> flexible than Drupal ever dreamed of being.  Definitely easier to use.

That's part of the point.  I can get a classified ad site up quick  
and easy.  But, oh -- you want paid subscriptions? hrm ... that's  
harder.  Considerably harder. Wait, you want a zip code search?   
That's also harder....

If I have to custom code, it's going to be MUCH easier under pmwiki  
than drupal or joomla or even xoops.

>  I have never really been involved with a wiki, but from the beginning
> saw PmWiki as the best (potential) CMS available.  Esp if you are
> database averse.  Like me.  There were a few things I couldn't do at
> first, but now ZAP has filled in those pieces for me, and more.  It
> replaces all my forum, commentboxes, newpage, new
> member/authentication recipes, etc, while adding lots of new fun
> stuff.  One of these days I'll put together a bundle based on ZAP for
> rapid CMS development.

I'm less interested in "rapid" and more interested in "customizable".

> Personally I think PmWiki should take on some of these CMS's out there
> head to head. I know it would blow them out of the water.

Yes, but not until the documentation is a bit better, and until there  
are good examples of active CMS applications out there.  I have 2 in- 
house projects to work on, and the incoming paying work that I am  
able to choose whether or not PmWiki is an option for.  I think it's  
too early to tackle PmWiki shopping carts yet, for example, but a pay- 
to-join could work, and work very well.

> Well looking forward to your classified ad project.  If you can
> specify the form you want, I'll (try to) write the snippet.

I'll let you know if I get the contract. In the meantime, I'm working  
on a page-rating function for PmWiki and I'm about 90% through it.   
I'm specifically not taking most of Patrick's recommendations on this  
-- they didn't feel PmWiki-like and I didn't care much if the script  
could be extending to rating everything under the sun.  There's  
something about rating a page or whatever the page is about (article,  
product, recipe, etc.) that's particularly important and I believe  
needs its own dedicated attention.  People can take the recipe and  
vary it for rating everything under the sun later, but I need basic  
functionality, and I need it a month ago ;)  I want it to be  
extensible, and have added some basic options such as whether to  
allow people to vote more than once.

Crisses