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
> 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
> 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
> 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.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!