So many interesting, thoughtful and thought-provoking responses - I am
overwhelmed. Thank you.
I can't reply to each of them - flooding the list with 24 responses
would be somewhat anti-social :-), so I'll arbitrarily pick the most
recent (as I type) and respond to it, with responses to various points.
A number of people have made perfectly sensible suggestions, musings or
"project proposals" that would constitute useful "CMS's to play to LC's
strengths, and avoid simply re-inventing existing wheels which already
in another language. I would love to do (or contribute to) many of those
- but I know I don't have the time or immediate need for them. So (for
me, for now) that rules out David's static-site generator scheme,
Andre's PWA and even much of Andre's Desktop with API.
I will definitely take David's advice ("be opinionated " :-), and I will
be mindful of the fact that 3 of the people whose opinions I most
respect (Ralf, Andre and Richard) all said something along the lines of
"stop - it's a huge task - make sure you know what you're getting into
.." :-)
So here's my current take (sorry for the very long email)
"CMS" is a broadly defined beast and it's important to fovus on what you
want it to mean.
To Ralf's point about the need for large amounts of "front-end" effort,
in-line editing, and "lots of Javascript" - that's true, for a certain
kind of CMS you would indeed need that - and I wouldn't even consider
building such a thing. The websites I have done to date (and am about to
update and build some more of) have people (not very tech-savvy) whom I
would call "content editors" adding / maintaining the *content* using
simple web forms (no JS, just plain-old html "Web 1.5" forms) and
Markdown-lite. I am happy for them to continue that, they had no
difficulty understanding a simplified version of markdown - I mostly
want to make it easier for myself (and other "site-creators") to enable
this, i.e. provide simple, easy, built-in access to forms and
"db"-update mechanisms without extra work for each new site.
Again - this should be *content* management only - whether the site
itself uses Bootstrap, or JQuery, or *any* other technology is entirely
up to the site creator, and the 'CMS' should allow that.
(Note - when investigating Wordpress, I really liked Visual Composer for
in-line editing and page layout - until I discovered that it was
incompatible with Pods Custom Post Type extension for anything beyond a
simple list - without significant PHP coding). So the page content
definition (described below) is simple - should cover 95% of all actual
pages :-)
And, finally for my "intro" - my preference has always been to put this
on top of revIgniter - and the responses have confirmed that no-one
would regard that as a disadvantage or problem - so I feel comfortable
with my original preference. Also, I have realized that my concerns
about the "rigLoadView" mechanism are misplaced - it's not "a problem
that they don't fit well with themes", in fact, it's a "solution that a
folder full of 'views' *is* one good way to define a theme".
On 04/12/2017 18:12, Richard Gaskin via use-livecode wrote:
We have many options available, and many different needs. Whatever
Alex finds as the best fit for the specific CMS he's aiming to build
will hopefully reflect less any fashion or trends or technologies
among the nearly infinite range at his disposal as it will reflect an
understanding of what constitutes an excellent UX for visitors of the
sorts of sites he's looking to build.
Here's what I am aiming at:
Summary: based on top of revIgniter, this will provide a controller
script to display any and all pages, with simple, easy-to-understand and
easy-to-use mechanisms to allow multiple people with varying skill-sets
to create, build, maintain a web site of simple to moderate complexity.
The long version :
revIgniter will be the base technology.
LCMS (or whatever more descriptive name I can think of) will provide a
primary controller script which will display pages as required, as well
as a set of web pages for updating the site content.
A "site creator" will create (and maintain) the site - providing the
(core) set of pages, the menus setup, choosing (or creating/extending) a
theme and setting up the initial admin interface; a fairly tech-savvy
person, most likely a LC scripter though I would hope that the majority
of straightforward sites such as I usually help people with will be
doable without any new coding).
A "site maintainer" will extend / update / modify the site content - the
info in the pages, uploading images or other media assets, etc. (Not
necessarily tech-savvy - but with some clue - able to edit markdown text
for simple content, and perhaps to copy/update simple command sets).
[Some page changes might be more structural and need the "site creator",
depending on the tech comfort level of the sit maintainer.]
An RDBMS (e.g. MySQL) will be used (as in the revIgniter default),
providing user management, etc., but (to allow the possibility of
Git-based roll-back, etc.) a number of features will be flat-file based.
So the things needed in a site are:
a theme: themes should be *site-independent* - i.e. usable with no
change (or an inheritance-based extension mechanism) on many sites.
These define whether (and more importantly) how (i.e. the html code
snippets as well as JS and CSS assets) to implement high-level
constructs (page headers for different page types, snippets for common
features such a banners, galleries, carousels, responsive grids of
images / mini-pages, etc. Themes will be implemented as a set of view
files in a View folder. As such, they are pretty "techy" and will be
defined by a "site creator" or perhaps a them creator for general use.
(NB first release won't include the inheritance/extension mechanism;
hey, I'll be licky if there are two themes defined in it :-)
menu and controller definition : the 'controller' definiton might well
be standard (i.e. only using the built-in features), or might need to be
extended for a site that needed custom coding. The menu definition
simply determines what pages are shown in the menu.
pages: the (initial) set of pages to be available on the site; note this
includes those directly available from the menu as well as possibly
others. These are flat-files (so suitable for Git-control). Each one has
a (optional set of intro definitions) and a simple text description of
the content. See below for definition of content.
A simple "media uploader / manager". This will be needed for images,
audio clips, etc. It will be *simple*, i.e. upload a file or a few
files at a time, no fancy JS drag / drop / select, fill in category /
tag / etc. form entries., etc. (Can probably also be used to upload
other things (e.g. markdown text files) for anyone who wants to do it
that way.) This currently will automatically build specific sized
versions of the images on upload (i.e. it won't automatically resize on
each access - that requires too much smarts on caching that I don't have
:-); these can be referred to as "thumb", "small", "medium" and "large"
- while the actual definition of those sizes can be set by the site creator.
Custom DB types: the site creator can determine custom DB Objects to be
used on the site. (Versions >1 might allow these to be DB or flat-file
??) These define the fields, field types, etc. in the DB, and
automatically generate a simple (dumb, ugly) form page to edit them.
Now we are ready for "Page Content"
Each page is described by a simple text file (flat file, in
/user/pages"). There will be some meta data (cf Grav CMS) optionally at
the head of the file, but the main file will consist of a series of
'directives':
"set",
"Banner",
"Carousel",
"mdl",
"html",
"image"
(more to come ...)
Any text outside these directive blocks will be simply output as is;
probably shouldn't be any of this.
A directive begins with a line enclosed in "[" and "]" with only
whitespace outside the brakcets, and has a directive name and possibly
argument, followed by "," and a number of 'details' each separated by
comma. In general, the theme will need to define one or more snippets
related to each of these directives. So it is assumed that the theme
will have an entry for 'banner', etc.
The current set of directives is :
"banner"
[banner, where Category=banner, orderby id=random]
Produces a full width banner image. The 'where' and 'orderby' clauses
are basically passed to the DB selection (of media asset type 'image'));
in my case, all images with category 'banner' are panoramas and I want
any random one of them.
"carousel"
[carousel, where category=hotel, name mycarousel]
Produces an image carousel (named so we can have more than one on a page).
"image"
[image size reference alternative text to show]
"size" is one of thumb, small, medium, large
reference is either a number (th eID) or the shortname of an image
alternative text to show is the 'alt text'
(Note - this should match the custom addition to Markdown - see below)
"html"
[html <type>]
The following lines (up to one saying [html end] are html text and
should be passed through unchanged. <type> is not yet really defined,
but will expect to match something in the theme.
"mdl"
[mdl <type>]
The following lines up "mdl end" are Markdown-Lite text. <type> is not
yet fully defined, but will expect to match something in the them -
currently only using "text-section" to include the header/footer for a
simple text section. 'mdl' stands for Markdown-lite - only handles basic
forms of Markdown (tbd elsewhere), but does also include some special
forms for LCMS
- ! - refers to an image from the media library, by
either id or shortname
NB the "text" part is image size reference alt text - to match a
"image" directive), while the part in parens is ignored
-  - standard Markdown
- ...[visible](url) - standard markdown, except that if 'url'
ends with "*" or "_NEW_TAB, then it will open in a new tab,
and if [visible] == [fb] then it will generate a Facebook link.
(other social media to come in later versions)
and (keeping the best for last :-)
"set"
[set businesses, where Category=hotel, title Hotels, count=3, template
businesses_grid]
Produces the output for a set of objects; the object type (e.g.
'business') determines the DB table, while the 'where' and 'orderby'
clauses would filter and sort those objects, and a template can be
defined to specify how they should be displayed, the title is a
mini-header before the display, and the 'count' determines how many
should be shown per row.
This is, obviously, the most complex and powerful of the directives;
note that it expects (requires) that the theme will specify both header
and footer snippets for each of "section", "row" and "item", while the
format of the entry for the actual object is specified in the "Content"
field of the "template" specified.
It is perhaps worth pointing out here that the html snippets
*surrounding* each object are part of theme (i.e. they define how to put
something *into* a "n"-grid, while the content template cannot be part
of the theme, because it will be dependent on the values to be displayed
- i.e. it's site-specific.
I hope to have this cleared-up in my mind, and an initial prototype done
for Christmas (which should allow an initial upload to Github by New
Years's).
Later,
Alex.
P.S. a page similar to
https://www.kilmelford.com/igniter.lc/basic/Businesses would therefore
be created by the page definition:
[mdl text_section]
<article>
## Business Directory
If you run a business in this area and would like to be included,
please use our Contact Info. If your business is already included,
and any of the contact etc. data has changed, please give your
input via the contact page.
The day/time/place information for visiting services (mobile library,
bank) can be found on the [Services Page](services) .
</article>
[mdl end]
[set businesses, where Category=hotel, title Hotels, template
businesses_grid]
[set businesses, where category=B_and_b, title Bed & Breakfasts,
template businesses_grid]
[set businesses, where Category=eating, title Places to eat, template
businesses_grid]
[set businesses, where Category=activity, title Activities, template
businesses_grid]
[set businesses, where Category=interest, title Places of interest,
template businesses_grid]
[set businesses, where Category=business, title Businesses, template
businesses_grid]
[set businesses, where Category=government, title Government, template
businesses_grid]
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
