[Webdev] Project suggestion: PHP Website Framework

[Nick Murtagh]

I'm going to ask what may seem like silly questions in order to clarify 
things in my head:

On Thursday 21 February 2002 21:58, adam wrote:
> /phactory          <- Phactory Root
>   /lib             <- Libraries Root
>     /phactory.php  <- Base Phactory Class
>     /frontend.php  <- Frontend UI Class
>     /backend.php   <- Backend UI Class

I have to say at this point I'm slightly confused by your use of the words 
frontend and backend. I would regard backend as referring to a "server" and 
frontend as referring to a client, but then how would the backend have a UI?

Do you mean backend for editing a site and frontend for viewing a site?

>     /db.php        <- Database Class (Obsolete)
>   /mod             <- Modules Root
>     /content       <- Content Module Root
>       /common.php  <- Base Content Module Class
>       /view.php    <- View Action
>       /print.php   <- Print Action
>   /tpl             <- Templates (Obsolete)

What is an Action? What does print.php do?

> Anyway, this should give a better idea of what I mean by 'modules' and
> 'actions', and how they would fit into the backend UI. Most of the new
> elements in the backend UI are obvious, but the Actions one is complex,
> because Actions relates both to the Actions available in a module, and the
> Actions related to a document (save, cancel, etc). These would need to be

Ok, an Action is an operation on a document, but why would you want to print
a document? 

> separated. But the concept is basically intended to address what you're
> suggesting - it would use cross-frame scripting (and loading) to target
> relevant forms in the main frame. (BTW, I've come up with a basic new UI
> for Phactory, but I haven't integrated it into the actual application yet.)

Your gonna use frames? Nooooooooooooooooooo

> I realise that I'm somewhat missing you point, but I'm doing that on
> purpose because I wanted to cover this before I went onto the idea of
> saving as against publishing. This is somewhat addressed with the idea of a
> "staging" database mentioned in my last post, i.e. all changes made by the
> user in a session would be saved to a set of staging tables, and queries
> saved to a dedicated table in that database. When the user was satisfied
> with the end result of his work, he would hit a publish button at the end
> of his session, and this would run all the queries again, this time on the
> live database.

So your going to keep some kind of log of actions peformed on the staging 
tables, and replay the queries against the live tables? That would be neat.

> This also ties in with the idea of the user working offline (let's not get
> into the reason we /have/ to work offline in Ireland, eh :). If we're able
> to build the staging system into this from the start, the Phactory
> application would handle remote and local publishing requests
> transparently - i.e. the framework for remote publishing would be there,
> the only thing we would need to address would be security and transport.

So is the user going to install PHP + database on his own machine? Presumably 
that's where the log is kept.

> > You might also make the "save" command implicit, and provide instead
> > an n-level "undo" command.
> That /is/ a good idea, but I think it may be too complex to build into the
> first (major) iteration of the application (although I'm open to argument).
> It would certainly be on the TODO list anyway.

Well, given that you already have the log as descibed above, it wouldn't be 
too hard. 

> little difference). At the moment, I /know/ only one developer will be
> working on a site at the same time, so this isn't a concern. My way of

Fine.

> handling this in the interim was/is cheap-and-nasty, that is just to block
> out users while someone is working on the site. Given the need for mutiple

That's a good idea.

> developer access, I'm inclined to agree with you that this kind of
> functionality would be a very early requirement. However it would need some
> major thought and discussion to get right.

It's the kind of thing the afformentioned webdav is targeted at.

Nick