Given that ExponentCMS is written in PHP and GAE-CMS is written in Python,
and that I have tried to maintain a very Pythonic codebase, I would say
that there are lots of differences. As I mentioned it is very roughly
based, for example you will recognise the directory structure and as
mentioned, the theming is very similar, Exponent also makes use of YUI in a
similar way.
I have yet to develop the permissions functionality however I have designed
it so that it can be added in later with ease. Currently permissions are
either all or nothing with the AppSpot admins given all permissions and
everyone else has nothing (except View permission on public sections).
However individual Content types are designed such that they must make
manifest all actions that they can perform. This will later tie into the
permissions system so that each action for each Content type on each
section requires a user with permissions to perform. So for example if you
had a Listing Content with actions edit_item, delete_item, create_item and
view_item, you would require explicit permission to perform each action
except view item which would fall back on your View permission for the
section. Again with sections you would have two permissions, View and
Manage. Manage would automatically give you permission over all actions
for all Content within the section.. Also I should mention that there will
be individual permissions as well as group permissions. This is exactly
how ExponentCMS deals with permissions
Currently user-created modules must be copied into the /framework/content
directory and deployed onto the server.
I'm not quite sure I understand the last sentence but I think it's asking
regarding how performance will be kept at a high performance. I've used
memcache at the Content level to make sure database queries are minimized.
Similarly resources such as CSS, JS, files, etc are cached and retrieving
them is relatively inexpensive. I have made every effort to minimize the
cost of the system.
Okay let's look at the /framework directory. It has in it an assets
directory. This is used throughout the system including for individual
Content types to store CSS and JS files. The only exception is
framework/assets which also has a statically defined images directory
containing the sprite image that is used for site management images. I had
skipped over this point in the first post but you can see it defined in the
app.yaml file.
The /framework/content directory defines all of the Content types.
Currently you can see these types include Configuration, Container, Files,
Navigation, Text, Themes and User. I think it is obvious what content they
each define by the name, but I will mention that they all are subclasses of
the main Content class. You can define your own Content type subclass such
as Forum for example and it shouldn't be hard to implement if you look at
how the others are done. The simplest one is the Text content which is the
most basic type of Content that allows you to use a RTE to enter some
static text/html snippet on the page and this is just 100 lines of Python
code plus the JS, CSS.
The /framework/subsystems directory defines various subsystems are used
throughout. These include cache, configuration, file, forms, permission,
section, template, theme and utils. The most important one to know is the
section subsystem. This one enables viewing a section, creating sections
and subsections, reordering, and a bunch of other section related things.
It works in conjunction with the Navigation Content which is used to
display various types of navigation such as dropdown, top level, children,
full hierarchy, etc. It also is used to display the current section in its
basic form or replace the main container (remember {{ main | safe }} with
the content of any action that is carried out on a type of content
contained in a section. If you understand the section module, you have
understood a large part of this CMS.
Finally the templatetags subsystem houses filters.py which define a bunch
of functions that are available at the template level.
Okay this is a brief overview. I hope it can help you as you're browsing
the code. Please ask for help when you need and feel free to contribute
directly to the project page.
Thanks,
Imran
On Friday, July 27, 2012 2:31:29 PM UTC-4, Bill Graham wrote:
>
> Hi Imran,
>
> Thanks for the intial data on GAE-CMS. I will take a look at ExponentCMS
> for more info. (This may provide a quick-start for the documentation for
> the various audiences.) Perhaps you could tell me what the primary
> differences are between GAE-CMS and ExponentCMS (perhaps some functionality
> you have not yet included and what the plans are re. those functionalities.
>
> Of the open source CMSs, I am most familiar with Drupal, which I tend to
> look at from a architectural perspective. Their "node" concept is very
> powerful as it allows common functionality to be easily applied to any
> content type (entity type). This works great for threaded discussion
> comments, for capturing the created by and dates, for managing entity
> status and workflow, etc.
>
> I think what would help me most right now is to understand the framework
> part. How are you handling the roles and permissions and how do you
> designate what objects/actions a permission pertains to?
>
> It would also be good to understand how user-created modules are included.
>
> Finally, what do you see as keying in keeping GAE-CMS beiing a high
> performance? I agree with you that this is crucial.
>
> Looking forward to more information.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/vs_-9ROy64wJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
