Re: [Pagekit-users] TODO List.

[Boris Z. <bo...@am...>]

Hi Rob,

a cool list. I like to share some thoughts.

Am Montag, 13. Oktober 2003 11:07 schrieb Rob Starkey:
> Hey,
>
> The current TODO list is pretty sparse and I'd like your opinions on a
> couple ideas I have.
>
> 1.  Authentication realms (ala tomcat):
>
> Right now I support an admin and member's area with wrangling of code
> inside common.  It would be nice if I could just add a few directives in
> the config file, point to a table in a database and assign the page/section
> to a auth realm.  It would also be nice to be able to change the cookie
> name (BTW postfix should really be called suffix) based off the realm. 
> This feature would also go a long way to help make pagekit an ideal
> framework for branding/whitelabel sites.  Instead of
>
> An example in the config file would look like this:
>
> <GLOBAL default_realm="members"/>
>
> <AUTH>
>   <REALM id="members"
>     table="members"
>     user_field="login"
>     pass_field="pass"
>     pass_type="MD5" (can also be cleartext, SHA1, crypt, etc...)
>     session_expires="+1h"
>     cookie_suffix="members"
>     login_page="member_login"/>
>
>   <REALM id="admin"
>     table="admin"
>     user_field="login"
>     pass_field="pass"
>     pass_type="MD5" (can also be cleartext, SHA1, crypt, etc...)
>     session_expires="+1h"
>     cookie_suffix="admin"
>     login_page="admin_login"/>
>
>   <REALM id="resellers"
>     table="reseller"
>     user_field="login"
>     pass_field="pass"
>     pass_type="MD5" (can also be cleartext, SHA1, crypt, etc...)
>     session_expires="+1h"
>     cookie_suffix="reseller"
>     login_page="reseller_login"/>
> </AUTH>
>
> <PAGES>
>   <PAGE id="restricted" require_login="recent" realm="members"/>
> </PAGES>
>
> <SECTIONS>
>   <SECTION id='Admin' require_login='yes' realm='admin'/>
>   <SECTION id='Members' require_login='yes' realm='members'/>
> </SECTIONS>
>

I like this idea. Do we need different tables to identify the users 
( members , admin, reseller )?

And why different login_pages? At the start all users are default_users, 
members in this case. Then at the default_login_page the user change to a 
reseller or to an admin. How does the user do that? Is it possible or desired 
that a users can be reseller and admin?

It would be cool if everyone think on his projects and thought what groups you 
need, how much groups, and so on. As the next step we work something out that 
match all or most cases.

In the past one user contributed a initial patch for a system with up to 32 
groups. We worked some days on it. Perhaps a start. 

> 2. Cookieless sessions.  If cookies are found to be disabled switch to a
> URL munged or hidden field session_id.  When a web app is used to accept
> money from customers turning them away for something as silly as having
> cookies turned off is bad.  I've spent many hours working around this
> problem and it'd be nice to have pagekit manage session ids in a more
> modern and built-in way.
>

Is this really worth the pain? And if so is someone here who has used hidden 
fields or a URL that carries the session_id. Lets share experience.


> 3. Better error reporting.  Right now, it's less then desirable.  It'd be
> nice to have an all round better error catching and reporting system.  I'm
> looking for input here.

Whats wrong with the systems we have already?

>
> 4. better caching.  This is on the current TODO list but it's not really
> defined.  I'd like the caching system NOT to blow away of all of my cached
> files at startup but rather delete the stale files and rebuild them before

We can add a config option to not blow away the cached files. PageKit do it 
right on startup in all cases I know, expect if you develop with pagekit or 
update to another version. But in the past, very often the answer was clear 
the cache and all works. So the default is to clear the cache on startup. 
Another very important future is that the format of the cache can change.

> accepting new connections.  Model output caching would be nice but pretty
> tricky to do.  Any ideas on that?

Not really I thought about it too, but without success. My Ideas are cache 
some model_tags, name them different ie: '<CACHED_MODEL_VAR xxx/>'
cache the content inside the cachefile or prefill it, Im not sure. But how do 
we know about updated data or a cached time?

>
> 5. apache2 and modperl2.  What's the current status on this?  Boris?
>

I can not find my installation. I retry and report where we get stuck. Im 
unsure but lasttime Apache::Request was the showstopper best to my knowledge.

> 6. add a 'truncate' modifier to the pagekit template tags.  For example
> <MODEL_VAR NAME='something' TRUNCATE='5'>.   Template-Toolkit has this and
> it would save me from having to do in the model code and let the designer
> define how big the output should get.

That is hard to do since we pipe the data to our templateengine. The right 
thing is to teach H:T to filter. Or we use TT. I have used tt instead of H::T 
already. But for another reason and they are very similar. I have done a tt 
port only to get some more speed. It turns out that both toolkits are at the 
same speed. H:T is faster or equal on short pages on larger (mode inserts ) 
pages TT is faster. Perhaps we can incoporate and beauty the patch.

>
> 7. pagekit managed multipage output.   This would be nice... but sorta
> fluff.  Maybe HTML::Pager would help.

This looks to me like PageKit for the poor. Or like a TT class. can't this be 
done with normal modelcode?  

But maybe I did not understand what it is good for. Lets talk.

>
> These are some ideas to stimulate discussion and have been on my own
> personal TODO list for a while... so let's discuss!  :)
>
> Thanks,
>
> Rob

-- 
Boris