[Maypole] Where are we up to?

[Jesse Sheidlower]

On Mon, Mar 08, 2004 at 11:46:18AM +0000, Simon Cozens wrote:
> I'm going to try and put a couple of days into Maypole and Flox hacking this
> week, and hopefully get a new Maypole release out, financial circumstances
> permitting.

Great!

> What needs to be done? I think I need to sit down and have a blitz on writing
> some decent documentation, test out CGI::Maypole, and try to get uploading
> working. Is there anything else that people are having issues with? Jesse,
> where are you up to at the moment?

Well, as long as you're asking....

I'll repost here some things I sent personally last week, and
add a few more things that I think could be useful. And always
more doc stuff, which I find myself needing as I try to figure
out what's happening when.

* Flox features should be mentioned in the wiki cookbook, if
not incorporated into the base app itself. There are neat
things in there that one only discovers from reading the
source. E-mail is an example--you should say somewhere how
to send e-mail from a Maypole app. Every time you hack on
Flox, you add something that would be good to have, or at
least know about, for other Maypole uses.

* Documentation for how to work with relationships would be
nice, esp. for those of us with less experience in CDBI.  For
example, to take Kake's rough framework in no_code, suppose
each book has_many review, and each review has_a
review_author.  To add a new review, you click on an "add
review" link from a book. It would be helpful to see a short
example showing (both templates and code) how the new review
picks up the book's id, and how to generate a popup menu with
the contents of the review_author table, and how this all
gets added.

(I realize that Maypole _does this already,_ but since it's
magical, it would help to see how it works so that if one
needed to modify it, one could write one's own routines that
do similar things. And I assume it would only take about a
paragraph to describe this.)

* Uploads, as you mention. Some flexibility would be good, so
that, for example, you could upload a picture with several
different descriptive fields [perhaps one of them being drawn
from a lookup table], that could be done. Or if the file is
being uploaded into an image table, instead of into a column
in the main table. That sort of thing.

* Security. I mentioned this last week on the list. It's
probably simple, but the basic requirement would be that
particular pages could be handled over an SSL connection
(say, the login page, and any access to the user table),
and one should be able to do this as needed.

* Searching. Perhaps some way of flexiblizing the search?
Say, instead of having to rewrite the entire search routine,
said routine could look for an assemble_search method which
would process the params into something suitable for sticking
into AbstractSearch. Then the search routine itself would do
the same thing, so that the existence of assemble_search would
override the built in search thing, but AbstractSearch would
be the base in any case. And, if you wanted to write an
especially complicated search, you could write the SQL
directly and inline it, again without having to totally
rewrite the search routine. (Or, docs showing how this could
be done if necessary.)

(I have a project that involves a number of non-small tables,
and CDBI wouldn't be able to handle it its usual way, I
need the raw SQL for speed.)

* More flexibility for the default templates? The way things
are set up now, the do_edit routine will always return you
to a "view" template--if you don't have a "view" template
(perhaps because you wanted to call it "displayfull", or
"sicht" or "vue" or "vista"), you're stuck, unless you want
to rewrite what should be a core routine.

That'll do for a start, perhaps, esp. as I have to put
aside my computer and hack out a bunch of definitions....
But I'll send some more thoughts to the list as I have
them.

Thanks for all your work on this!

Best

Jesse