view release on metacpan or  search on metacpan

lib/App/Office/CMS.pm  view on Meta::CPAN

=item o How is the code structured?

MVC (Model-View-Controller).

The sample scripts I<cms.cgi> and I<cms.psgi> use

	prefix => 'App::Office::CMS::Controller'

so the files in lib/App/Office/CMS/Controller are the modules which are run to respond
to http requests.

Files in lib/App/Office/CMS/View implement views, and those in
lib/App/Office/CMS/Database implement the model.

Files in lib/App/Office/CMS/Util are a mixture:

=over 4

=item o Config.pm

This is used by all code.

=item o Create.pm

This is just used to create tables, populate them, and drop them.

Hence it won't be used by L<CGI> scripts, unless you write such a script yourself.

=item o Logger.pm

This simplifies logging by allowing me to say:

	$self -> log(debug => 'A message');
	$self -> log(info  => 'Another message');

=item o Validator.pm

This is used to validate CGI form data.

=back

=item o What's the database schema?

See docs/cms.schema.png.

The file was created with scripts/schema.sh, which uses dbi.schema.pl.

That program is a version of dbigraph.pl, which ships with L<GraphViz::DBI>.

=item o Does the database server have pre-requisites?

The code is DBI-based, of course.

Also, the code assumes the database server supports $dbh -> last_insert_id(undef, undef, $table_name, undef).

=item o How do I back up the database?

See the config file .htoffice.cms.conf:

	backup_command = pg_dump -U cms cms
	backup_file = /tmp/pg.cms.backup.dat

When backup_command has a value, the Edit Contents tab gets a [Backup] button, and when this button
is clicked:

=over 4

=item o The command is run

=item o STDOUT and STDERR are captured

=item o If STDERR contains anything, the program exits

=item o Otherwise, STDOUT is written to the output file

=back

So, why are there 2 lines, and not something like 'pg_dump -U cms cms > /tmp/pg.cms.backup.dat'?

Because I use L<Capture::Tiny>, which does not want you to use redirection.

Lastly, the output is written using L<File::Slurper>.

=item o What's this thing called 'context' in the menus and pages tables?

It's the value ("$site_id/$design_id") which ties those 2 tables together, just like a foreign key.

=item o What are these fields menu_orientation_id and os_type_id in the designs table?

I originally allowed the user to select a horizontal or vertical menu format, when generating pages.

The vertical menu is just the tree I ended up with.

I decided not to support horizontal menus, at least in the short term, because of the width of such a menu
when the page names became long. It would have appeared just above the site map on the Edit Pages tab, and
would have been clickable in the same way the site map tree is.

The os_type_id is for the unsupported code which generates pages in a directory structure for an OS
different from the one the code is running on.

You can ignore these 2 fields, and the other 2 tables, menu_orientations and os_types.

=item o I added a field to update_page_form, but it's data vanishes.

Basdically, copy the code dealing with 'homepage'.

At the very least, ensure you've updated:

=over 4

=item o App::Office::CMS::Util::Create.create_pages_table()

=item o App::Office::CMS::Database.build_default_page()

=item o App::Office::CMS::Controller::Page

=over 4

=item o build_page_hash()

=item o build_success_result()

=item o check_page_name()

=item o update()

=back

=item o App::Office::CMS::Util::Validator.validate_page()

=item o App::Office::CMS::Database::Page.save_page_record()

=item o App::Office::CMS::View::Page.build_update_page_html()

=back

For site data, start with App::Office::CMS::Controller.build_site_hash().

lib/App/Office/CMS.pm  view on Meta::CPAN

=item o Why didn't you use accessors::classic/Class::Accessor/Object::Tiny/...?

For various reasons:

=over 4

=item o accessors::classic ...

... does not parse the parameters to new().

=item o I wanted ...

... to have BUILD() (or even init() ) called after new().

=item o Class::Accessor::Constructor ...

... will call init(), but it also drags in another set of dependencies.

=item o Object::Tiny ...

... does not have attribute setters.

=item o With Mouse, ....

... a syntax-friendly upgrade path the Moose is preserved.

=back

=item o Will you adopt DBIx::Connector?

Probably.

=item o Do I need Apache?

No. L<Starman>, part of Perl's L<Plack> project, is recommended.

See the sample code in httpd/cgi-bin/office.

=item o What other CMS's are there?

Heaps: L<http://cmsmatrix.org/>.

=item o Lastly, a plea

With your co-operation, I'd like to reserve the namespace C<App::Office::CMS>,
and perhaps even C<App::Office::Wiki>, for my own code.

Of course, you're I<much> better off using a TiddlyWiki
L<http://tiddlywiki.org/wiki/Main_Page> than waiting for me to start writing a wiki.

For massive wikiness (as distinct from wickedness :-) I draw your attention to
both L<Silki> and L<http://foswiki.org/Home/WebHome>.

=back

=head1 TODO

=over 4

=item o Adopt Git::Repository for versioned backup

=item o Clean up error handling

For example, when build_error_result is called, rather than build_success_result, the
data sent to Javascript must be handled slightly differently.

This includes HandleError in DBI's connect() attributes.

=item o Make asset handling more sophisticated

=item o Add begin/end transaction

=item o Probably need Javascript hash for menu item <-> id

This would allow the client to pass the menu item's id to the server, instead of the text

=item o Need to document handling of &amp;

=item o Do we need separate editor windows for each page's head and body?

=item o How will we handle moving sub-menus?

We don't.

=item o Ship with SQLite activated, not Postgres

=item o Consider using <span> instead of <div>

=item o Auto-generate a site

=item o Auto-generate a design for a site

=item o Enhance New Site tab with an Edit Site button

This saves the user the effort of going to the Search tab to find a site or design

=item o When clicking on the site map, the Edit Pages fields are updated, but the Edit Content fields are not

=item o Add an option, perhaps, to escape entities when inputting HTML

=item o Adopt DBIx::Connector

=item o Implement user-initiated backup and restore

=item o Change class hierarchy

This is so View does not have to pass so many parameters to its 'has-a' attributes

=item o Adopt L<CGI::Untaint::html> or L<HTML::Defang>

Considered and rejected: L<HTML::Sanitizer>, L<HTML::Scrubber>.

=item o Test CGI::Untaint as to its handling of <script>...</script>

=item o Investigate Quicki's revision system

=back

=head1 Repository

L<https://github.com/ronsavage/App-Office-CMS.git>

=head1 Support

Email the author, or log a bug on RT:

L<https://rt.cpan.org/Public/Dist/Display.html?Name=App-Office-CMS>.

=head1 Author

L<App::Office::CMS> was written by Ron Savage I<E<lt>ron@savage.net.auE<gt>> in 2010.

Homepage: L<http://savage.net.au/index.html>.

=head1 Copyright

Australian copyright (c) 2010, Ron Savage.

	All Programs of mine are 'OSI Certified Open Source Software';
	you can redistribute them and/or modify them under the terms of
	The Perl License, a copy of which is available at:
	http://dev.perl.org/licenses/

=cut