[Webdev] Project suggestion: PHP Website Framework

[adam]

Nick said:
> From the sounds of this you've been planning server side stuff.
>
Oh, I've rolled out server-side stuff, it's just that the project has been
re-engineered and recoded so many times now it's getting out of hand. I have
this concept in my head of a very cool webapp, but now that I've switched to
OOP (the project is large enough to justify it), I have difficulty with the
core layout. I need help, untimately. However, the original (procedural)
source was used for a flower etailer (that never took off) and is live on
www.flemingcontruction.com/home/, including a backend interface. I'd be
happy to give people a peek, but it's very immature at the moment. That's
why I'm here.

Just to move onto a slightly related point, I would also intend at some time
in the future to create advanced server-side modules, for actual server-side
administration, i.e. mail mappings, database administration, etc. Somewhat
like Webmin, but again, far less complex, and of course with a close eye on
security. The intention would be to log administrative requests to MySQL,
and have them actually performed by cron, to separate the user from security
breaches. In most cases, these actions would have to be actively approved by
an administrator with greater power.

> What would it look like from the client's point of view? It's possible
> to do fairly good WYSIWYG website development with modern browsers (but
> hard work). Or is this more of a fill in forms and click OK kind of
> thing?
>
At the moment, it's fill in forms and click ok. The CMS module, for example,
has several obvious fields: intro, keywords, content, panel (like a
sidebar), etc; you fill in the form and click ok, and when someone loads a
page with the key (the key is the URI, minus prepended module/action), it
generates the page accordingly. In the original draft, it was a hierachal
setup, with pages loading categories and articles (or products) based on
child records (if the $content field was empty, it was a category), but the
latest version was a bit icky, so it generated each page specifically.

As you say though, it's possible to do WYSIWYG with modern browsers, and
that's the way I would be heading. There are several Open Source DHTML
widgets to handle this, but they would need hacking. We would also need to
settle on a browser and work exclusively with that. Up until now, I have
been working exlusively with MSIE, but I would prefer to move to Mozilla
support. This of course would entail "forcing" the browser on the user, but
this shouldn't be a problem, because we would only be forcing the site
admins to do so. The only worry I have is that I would like this to be
portable, and administrators may not be able to work in, for example,
cybercafes.

Lee said:
> Does it rely on your clients having programming skills ?
>
No, that's the whole point. Administration would be entirely through the
web-based control panel. As I said to Nick, the intention would be to
eventually include a DHTML WYSIWYG widget to handle HTML generation, but in
the interim, I see no problem with using UBB or vBulletin-style codes as a
HTML replacement. I already use this kind of thing to a degree on
www.corkslang.com, although it actually uses Discus-style codes. The only
disadvantage is in runtime - the parser takes a little time to do
search-and-replace. That said, if the client /does/ have a programmer
on-board, they will be able to hack and tweak to their hearts content. So it
would be scalable - for a regular users, it's handy, neat and easy to use.
For an advanced user it's hackable. The hope would be that the hackers would
contribute back to the community.

> If yes then whats your selling point ? If no then how does your
> ordinary client user "use" it ? Is it a point and click, fill out
> forms jobbie (in which case it'll never be a dreamweaver :P) or a
> template driven / XML / upload your content and press the start
> button type of thing ?
>
All of the above. :)

For the most point, this is asked and answered, but one other aspect that
you've touched on is file uploads. No, it will never be a Dreamweaver
replacement (it's not intended to be), but that doesn't say you can't use
Dreamweaver -- one aspect I've been keen on for a while is an
upload-and-parse widget, whereby users upload (or copy and paste) an entire
HTML file, and it is parsed into it's basic elements (keywords, intro,
content) and INSERTed into the database in it's "native format". This would
allow people to work comfortably in Dreamweaver and just fire it into the
site.

As to templates, at the moment it uses basic templates from the filesytem,
with simple variable replacement, but it would be my intention to move
towards a vBulletin-style templating system, with "major" templates (whole
pages) and partial templates (bits). I would seek to simplify the vBulletin
system a little though. This of course adds queries and complicates SELECTs,
and this is another reason I want to go public domain - we need a SQL guru,
or at least an expert.

> If its help or hands you're looking for, apart from having zero free-time
> and very little PHP, I'd certainly like to have a go. Might be a good time
> to pickup PHP by doing bug-testing or something.
>
Indeed, but also, part of the project would be design-oriented, i.e. I don't
want another fantastically thought-out and hacked webapp with a manky UI
that puts people off. It should be simple, easy to use, and because we would
be mandating a browser, it should use advanced client-side programming to
boost productivity and simplify the whole system. There is an inclination in
the OSS webapp world to oversimplify; I want to avoid this, I want to use
the technologies that are available.

> Finally, why didn't you do it in Perl ? :P
>
You shouldn't need to ask that question. I certainly don't feel the need to
answer it... :)

Kate said:
> Sounds interesting. What would it have, that say, Midgard doesn't have,
> or couldn't be done ? It's a big job, and Midgard did seem to have most of
> what you were talking about, when I last looked at it...
>
Very little, and again, that's kind of the point. The main thing it
/wouldn't/ have in common with Midgard would be the binary. Midgard is a
Great Pretender at the moment, it's trying to be an advanced content
management solution and it's failing miserably due to it's complicated
setup. It requires custom setup, it requires complex installation, and it's
tricky to work with. That's not to say Midgard is a bad application - it's
certainly not - but it's not what I'm aiming for. If Phactory could be
compared to anything, it's Zope (because it's an API built on top of an
API), but again it's far less complex, and it's intended to be.

Phactory is intended to sit in the middle, aimed at small to medium-sized
websites, and not only that, it is /not/ intended to be a CMS. The aim is to
create a framework for a complex website that can be managed though the web,
and although that /includes/ content management in the traditional sense,
it's intended to be much more than that. Ultimately, I would like to include
every possible "widget" that people could want to have on theis site, such
as: FAQ's, forums, forms, press releases, membership, product catalogues,
shopping baskets, etc, etc. Each "widget" would have a separate module that
could be enabled or disabled by the adminsitrator, and would have a set of
Phactory methods available to it, such as user/group authentication,
site-wide session-management, etc.

It should be possible to develop these modules using as little native PHP
code as possible; simply dump them into the filesystem when you're done; and
call them up using a rewritten URI (/phactory/module/action/key for the
frontend, /phactory/admin/module/action/key for the backend). Again, the
ultimate goal would be to use PEAR standards and eventually have the core
framework accepted into the PEAR CVS tree.

If any of you have more questions, I would be happy to answer them. I'd
prefer if you asked to be honest.

adam