Mail archive
acf

Re: [Acf] RFC: attempt to "simplify" acf

From: Natanael Copa <natanael.copa_at_gmail.com>
Date: Tue, 31 Oct 2006 14:45:48 +0100

On Tue, 2006-10-31 at 00:21 +0000, Nathan Angelacos wrote:

[ snip ]

> > The rest of the webconf can be considered as the old "generic.view". It
> > will create the header and the footer. (yes, if you dont want that, then
> > dont use webconf. creat another front controller)
>
>
> hmm... In the default case, that's great - but what about the case of
> log files, where the action is to download a logfile as a mime-encoded
> text attachment, or a CRL list from the OpenSSL CA? (or... a
> dynamically generated .png file... or you get the idea.)
>
> In defense of "generic.view"... ;-) for most cases, you are correct -
> webconf can generate the header, menu, stylesheet, etc. but in the
> exceptions, do you really want another front-controller?
>
> If we have one front-controller, then session management,
> authentication, user control, etc can all be managed at the front
> controller. If multiple front controllers are created, then there are
> multiple points of entry into the application (as a whole), and multiple
> points of failure on authentication/session management.

Yes. This was exactly how I was thinking too, before.

> Its a two-edged sword - either you have one front controller, that can
> fan-out into multiple views, or you have multiple front-controllers that
> manage the same authentication mechanisms.

I understand. I used to think so too. but...

When I started to look at simplifying the old webconf, I looked for ways
to move as much as possible out from there. I think that the
authentification code would not be in webconf at all, but in a library.

So the front webconf would look like:
#!/usr/bin/haserl --shell=lua
<?
require "cf"
require "web_auth"

auth = WebAuth:new()
auth:check_authentification()

cf = WebCfObject:new()

cf:init( ENV.PATH_INFO, FORM )
cf:init_uri( ENV.SCRIPT_NAME )
cf:run_controller()

?>
<html>
...
</html>

The auth:check_authentification() would look for a session coockie and
if there si no valid one, it would forward the user to a separate login
page. (IE, www/cgi-bin/login)

This page would also have a require "web_auth" at the top.

> I adopted the single front controller, and used "generic" as the view of
> last resort. Unfortunately, I think most people thought "generic" was
> the "one-true-view", so it got overused.
>
> Is there some way that the controller could override the view info, so,
> that, for instance, the header/menu/tabs/ view:content footer/etc. are
> all rendered, but if there is an exception, the controller (or view) can
> inform webconf *NOT* to render everything?
>
> That is, in the default case, the view:content is rendered inside a
> <div=content> </div> block, but if the view decides it needs something
> else, it can prevent that, and render the entire page itself?

I intentionlly wanted to avoid that. I wanted to have simple rules for
the acf developer and try to avoid special cases.

Old:
1. look for model, view and controller
2. if controller is missing generate a "core" event to load the core
controller. (btw. what happens if the core controller is missing?)
3. if there is a .view, use it. if not then look for a view in acf_core
4. if view hint is something else then ...
5. if ... and then ...

So there are lots of things for the acf developer to know.

New:
1. look for model, view, and controller.
2. if any is missing, give up.

And that is it!

Now if you want to make a raw view, that dont show any header and
footer:

www/cgi-bin/rawview:
<?
require "cf"
require "web_auth"

auth = WebAuth:new()
auth:check_authentification()

cf = WebCfObject:new()

cf:init( ENV.PATH_INFO )
cf:init_uri( ENV.SCRIPT_NAME )
cf:run_controller( FORM )

cf:view:raw( cf )
?>

That means you have to have a function declared in the view that is named "raw"

foo.view.lua:
require "GenericWebView"
local me = GenericWebView:new{}

function me:raw( cf )
        self:content( cf )
end

return me


Now, if you run: rawview/prefix/foo/act

act() in prefix/foo.controller.lua will be executed and
foo.view.lsp will be displayed, without the header footer as in webconf.

So, the idea is, instead of add alot of complexibility to by trying to
handle all kinds of future exceptions in one frontend controller, we
handle each exception individually.

> That would allow binary downloads, graphics, etc... while covering the
> generic case 90% of the time.

I doubt there are that many exceptions and they can mostly be grouped
together (download binary file, png data, xmldata, ajax/text) and
handled when the need arises.

And if the auth is well implemented, in a separate lib, it does not
matter from what front executable the auth call comes from.

>
> > The new webconf will always try to run cf.view:content() unless the
> > cf.success is set to false. Its up to the view to handle errors.
> >
> > The missing parts so far are authentification and menu rendering. I'm
> > thinking of a auth.lua lib that contains an object to handle that. I'm
> > also thinking of adding session handling in haserl so you have a global
> > SESSION variable, just like ENV and FORM.
>
> I was planning on managing this in the front controller (webconf). what
> are you thinking?

Um... not thinking so much. I was thikning of php's session variable
that php handles. (I forgot how browser coockies works right now...)
Might be that it can be handled in lua code, but then, put it in a
completely separate library:

  require "sessions"

Actually the seesions module could be called from the "auth" module. So
the front webconf will only need:

  require "auth"

or something like that.

...

> > PS. a quick thought.. what if we included the menu in name.view.lua?
> >
>
> Its /possible/ to have a single controller/view pair in multiple menus.
> Imagine the generic "logfile" view, for viewing all log files, and the
> "OpenVPN logfile tab" under the OpenVPN menu. The controller/view is
> the same - the only thing that changes is the menu (originating
> controller) it was called from.
>
> That's why menu was in a separate file.

Ok. I think I'll keep it in a separate file.

>
> Thanks for your work on this, Natanael! Its looking good.

You havent even looked at it ;)

I'm still struggling with how the data should be passed over from the
webconf to controller to view.

--
Natanael Copa
Received on Tue Oct 31 2006 - 14:45:48 GMT