[Webdev] Project suggestion: PHP Website Framework

[adam]

> > You're just being difficult now Nick. :)
>
> I am :)
>
I feel slighted now, that's normally my job!

> But I can't believe your proposing on webdev at _linux_.ie to standardize
> on a web browser that only runs on proprietary platforms, is completely
> insecure, and isn't particularly standards compliant.
>
Ah, but I didn't propose that. What I said was that the backend UI is
currently MSIE-targetted, but that I would prefer to move to compliance with
the Mozilla DOM model. Lee disagreed.

> OK, I see what you mean. Dreamweaver for the templates, Phactory for
> filling in and managing the templates. Makes sense.
>
It might very well make sense, but that's not what I'm suggesting. :)

You're not to blame in this case though, because I haven't been entirely
clear about this. I'm suggesting that the default backend UI be entirely
web-based, initially with standard form fields and perhaps UBB Code for
formatting; but moving towards a DHTML WYSIWYG widget as we progress.
Dreamweaver "integration" would be on the TODO list -- we would aim to at
some time in the future to support a system whereby the user can (copy and
paste | upload) an entire HTML document into a form field, and Phactory
would parse it on submission into it's relevant elements, such as $title,
$intro, $keywords, $content, etc.

This is a relatively simple thing to achieve, by providing a mechanism
whereby the user could dump a "template", complete with placeholder
comments, to the user for download. This template could then be imported to
Dreamweaver and used for future article or item development. Again though,
this would be on the TODO -- just another thing I would like to see, to
offer as many options to the user as possible.

> Some ideas:
>
Excellent! However, I have to make a disclaimer first: I've thought of some
of these already, and I'll probably come across as a know-it-all
son-of-a-bitch when I say that. Not much I can do about that, so tough. :)

> You have a "save" command which checkpoints the user's work, and a
> "publish" command which makes changes visible.
>
The "save" thing is something I've wanted to do for some time, but haven't.
At the moment, Phactory loads up all the Phactory elements in a single
standard single-frame document, with a regular submit button on
form-submission pages. I want to separate out the Phactory elements, into:
Logo/Branding, Master Configuration, Modules & Actions. I need to give you
an idea of layout before I continue:

/phactory          <- Phactory Root
  /lib             <- Libraries Root
    /phactory.php  <- Base Phactory Class
    /frontend.php  <- Frontend UI Class
    /backend.php   <- Backend UI Class
    /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)

The above is a mix of current and future Phactory layout. For example,
db.php is now replaced by PEAR_DB, and I would hope to move templates into
the database. Also, the 'print' action and 'common' Content base class are
not in the current iteration, they are an example of how I would /like/ to
see the layout. PEAR would be used as a reference to create the structure.

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
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.)

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.

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.

> 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.

> You might allow the user to tag known-good versions of the site,
> for backup or release purposes.
>
That would be fantastic too, but it again ties into the Undo thing - it
would require a major (mental) redesign of the current framework.

> Next you worry about multiple users working on the same site, including
> the ability to "lock" a page for editing and later "release" it, or even
> fancier, the ability to work on a page in parallel and "merge" changes.
> (This is harder to implement, and probably not necessary for website
> developers).
>
Again related to Save/Undo, but far more important that the previous two to
my mind (even though they could all be integrated anyway, so it makes 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 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.

Thanks Nick,
adam