|
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
View previous topic :: View next topic |
Author |
Message |
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Thu Aug 14, 2003 5:31 pm Post subject: Smarty with an Object Orientated Website |
|
|
First, you can visit the website at http://www.habiforum.nl (In Dutch only, but the design is great (not my work))
I'll explain how the website is built.
In a (object orientated) database I have a Objects-table which contains all objects that can be views (by passing the ID into the query string). Each record contains the following crucial information:
ID
ObjectType
IsHidden
IsPublished
Now the key to this system is the ObjectType. Within the database I defined several different Objects such as: Page / Newsitem / Publication / Project / Person / Agenda.
Each objecttype has it's own template (also defined in the database). Furthermore, each object has a certain set of properties, which are saved in another table (three actually; one for char types, one for date types and one for fulltext). Properties I defined are, aming others: Title, Description, Content, Date, Price, Name, Surname, Sortorder, Loginname, Password.
In the definition table, I connect different Objecttypes with the properties:
Page has: Title, Description, Content
Agenda has: Title, Description, Content, Date
Publication has: Title, Description, Content, Price
Person has: Name, Loginname, Password
In this way, you can define (new) Objects, with a set of characteristic Properties, with a corresponding template. When I Need a new object, an Organisation for example, I just create a new ObjectType, with the apropiate Properties and make a Template to display it.
Now, after the objects are defined you need some kind of relation between them. One of the most used relation is the parent-child relation. In a seperate table I register relations between objects. Relations I defined are:
Parent: Object A has parent Object B, for navigation purposes
CreatedBy: Each object has a creator, which is a Object of the 'person' type
Contact: Each object Project has a Contact person
Let's go to the Smarty Part. Each Object has a template for displaying it to the visitor. These templates are stored in te database as Smarty templates. The PHP file which processes the request works in the following way:
1. Request is made: Object ID=3
2. Find all Properties (of type Date, Char & Text) and assign them to Smarty
3. Find the Template corresponding the ObjectType
4. Parse!
If you understand the Object Orientated Database, you can image that a CMS for all different ObjectTypes can be generated, because the definitions of the objects reside in the database too.
Last edited by mocean on Wed Sep 03, 2003 10:01 pm; edited 1 time in total |
|
Back to top |
|
messju Administrator
Joined: 16 Apr 2003 Posts: 3336 Location: Oldenburg, Germany
|
Posted: Thu Aug 14, 2003 5:53 pm Post subject: |
|
|
the site looks great and responds fast. your explanation is interesting. may i ask what oo-database you use?
greetings
messju |
|
Back to top |
|
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Thu Aug 14, 2003 6:51 pm Post subject: |
|
|
messju wrote: | the site looks great and responds fast.
|
I use Smarty caching too, response times, when cached, of about 0.08 sec
messju wrote: |
your explanation is interesting. may i ask what oo-database you use?
greetings
messju |
I use MySQL, but the design of the tables is object orientated
Tables:
Objects
ID
ObjectType
IsHidden
IsPublished
ObjectTypes
ID
TypeName (Name of the objecttype: page /project /person)
Template (Contains the Smarty template to display it)
ObjectProperties (Contains sets of properties of an object)
ID
ObjectTypes_ID
Property_ID
MultipleAllowed
Required
Properties
ID
PropertyName (example: date, title, name)
Datatype (char/text/date)
PropertiesDate / PropertiesText / PropertiesChar (Value has a different datatype in each table)
ID
Objectt_ID (corresponding object)
Value
Properties_ID
Relations
ID
RelationType_ID
ObjectA_ID
ObjectB_ID
RelationTypes
ID
Name (name of the relation: contactperson, parent)
I'll draw a picture with the model soon...
I understand it's rather difficult to explain/understand, but I'll answer all questions |
|
Back to top |
|
AZTEK Smarty Pro
Joined: 16 Apr 2003 Posts: 235 Location: Purdue University
|
Posted: Thu Aug 14, 2003 7:29 pm Post subject: |
|
|
Its an interesting concept, but given PHP's limits on OOP I am sure it will be better once PHP5 rolls arround. _________________ "Imagine a school with children that can read and write, but with teachers who cannot, and you have a metaphor of the Information Age in which we live." -Peter Cochrane |
|
Back to top |
|
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Thu Aug 14, 2003 10:45 pm Post subject: |
|
|
AZTEK wrote: | Its an interesting concept, but given PHP's limits on OOP I am sure it will be better once PHP5 rolls arround. |
The funny thing is, I use an OO Database, but the progamming itself is not OO, and rather straight forward.
I have one index file which handles all requests, as stated earlyer:
1. find object & corresponding template
2. Assign alle variables
3. Parse the template
Just a few loops.
The CMS part, with variable forms for all properties is much more difficult.
The good thing is, some properties can be assigned multiple times. An agenda item, for instance, can have several dates. The template is prepared for that and loops trough all dates while displaying them.
Database model:
|
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Sat Aug 16, 2003 12:07 am Post subject: |
|
|
Beautiful. I particularly like the db-backed metadata approach. I'm curious as to how you implement the rendering pipeline. I use a similar strategy (very different implementation, though) and I use generic templates to render application specified blocks.
I think an article describing your design in more detail would benefit more than a few users, if you have the energy for that |
|
Back to top |
|
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Sat Aug 16, 2003 11:16 pm Post subject: |
|
|
boots wrote: | Beautiful. I particularly like the db-backed metadata approach. I'm curious as to how you implement the rendering pipeline. I use a similar strategy (very different implementation, though) and I use generic templates to render application specified blocks.
I think an article describing your design in more detail would benefit more than a few users, if you have the energy for that |
An article may be an idea, I'll think about that.
The page rendering in more detail:
Analyse request
1) Does the object exist
2) If it published, continu (if not, throw a login, try)
Paths in the website
I implemented the parent-child system trough the Relations Table. On of the advantages is, you can assign mutiple parents to a page. This causes a problem, because I want to build a path recursively, to show the visitor where he is (example: Home > Contact > Route).
To fix this, I log every step a user makes in the website. Ehen, during the building the path, the script finds two parents, it looks which of the 2 was last visited by that visitor. The path is assigned to a variable to be used in the header-template later.
Variables
For each propertytable (Char, Text, Date) I loop trough all properties of the corresponding object, and assign the values to the variablenames from PropertyTypes. This propertysystem allows multiple values of a single property (agenda-items can have several dates for instance). When the script tracks a value that has been assigned more then once, the variables are stored in an array. The templates are prepared for that (only a few properties are useful to assign more then once)
cache key
Because I use Request-variables on some pages, and Paths can be different on a single page, these information is combined in the cache-key, which consists of: [ID]_[ReferrerID]_[NewsId]
NewsId is often 0, and for most pages the ReferrerID is often the same, unless it has two parents of course.
Smarty Settings
In the database I also saved information about caching. Some pages are cached 'until update' in the CMS, som dynamic pages are cached 10 minutes, some may never be cached. Furthermore, I check if a template or object has been changed, to force recompile/recache.
Parsing
The templates for each objecttype are stored in the database. I have created functions (database resource funtctions) which retrieve the template corresponding to the objecttype. In this way the the object is displayed with the appropiate template. |
|
Back to top |
|
risto Smarty Rookie
Joined: 26 Apr 2003 Posts: 21 Location: Norway
|
Posted: Mon Aug 18, 2003 10:38 pm Post subject: care to post the mysql structure? |
|
|
I'm very impressed so far. But It very much like to se the mysql structure export of your setup. youd you mind posting it? |
|
Back to top |
|
CirTap Smarty Pro
Joined: 04 Jun 2003 Posts: 106
|
Posted: Mon Aug 18, 2003 11:41 pm Post subject: |
|
|
Hi,
this is indeed some nice peace of work.
I'm just curious if there's also some authorization mechanism, e.g. who's allowed to edit/see what property of what object and/or if there are objects/properties only visible to certain people. If such thing exists I'd love to hear at what stage of the process you determined all the required grants for all objects involved.
We're working on some role-based authorization system, which is built around a similar concept but focused on the actions a user can perform with an object. For all "actions" (create, edit, delete, view), appropriate roles can be defined to determine the grant level for owner, editors, readers, managers, etc.
Properties and values are kept entirely in a bunch of PHP classes and those classes "know" their Smarty template.
The process of finding all roles and "access-levels" a single user can have for all the possible objects on a page came out to be pretty complex task, and unfortunately is still a performance issue if this information has to be (re-)evaluated on each request.
We're currently testing some "cache tables" holding redundant information about page-object-actions relationships and the roles necessary for each. Same applies to the roles and (possibly nested) groups that apply to a user.
Many roles are inherited from an object's parent classes and the tree-traveling and resolving of groups/roles is the most time-consuming.
I'd like to read this article as well in any case - with or without auth-system
Cheers.
CirTap |
|
Back to top |
|
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Tue Aug 19, 2003 10:17 am Post subject: Re: care to post the mysql structure? |
|
|
risto wrote: | I'm very impressed so far. But It very much like to se the mysql structure export of your setup. youd you mind posting it? |
Mysql dump
For the convenience in my earlier posts, I used easier fieldnames and I simplified my tables a little, because my website has a lot of links with external XML objects, which can also be linked trough the 'Relations' Table.
CirTap wrote: | Hi,
this is indeed some nice peace of work.
I'm just curious if there's also some authorization mechanism, e.g. who's allowed to edit/see what property of what object and/or if there are objects/properties only visible to certain people. If such thing exists I'd love to hear at what stage of the process you determined all the required grants for all objects involved.
|
On the client side I have a authorisation system in the following way. Each object has the property 'IsRestricted'.
When the object is retrieved from the database, and IsRestricted returns true, I throw a login-header to the client (if the client is not logged in yet).
I verify this login by a Relation of type 'ViewAllowed' with the 'Person' Object. Persons also have a property 'siteadmin' which allows them to see all Objects. I am going to create user-groups, so I can assign a whole grou to a page for viewing. Now a lot of relations are necceserrey.
In the backend I have prepared an authorisation system for editing, but the CMS is not ready yet (I have a CMS which can edit/create all objects in a htaccess protected directory, I'm the only webmaster right now).
I can create several persons, and connect them with objects, the relation is called 'EditAllowed'. With that relation they can edit an Object and optionally all children of that object. Some Persons are allowed to create new objects, or to publish an object.
I'm thinking about using groups of people (example: webmasters / editors / users). The good part is, suchs an adaption is really easy to make. I create a new objecttype called 'usergroup', in which I define the group's rights (gew new PropertyTypes), then I create the groups and define a relation 'InGroup'. With that relation I can put people in (several) groups.
The security of the CMS will be quite complicated. For instance, only site-admins are allowed to create other/alter persons, and use some Smarty-code (like {php}, includes ). Plugins (I created) may not be used by people other then webmasters.
(I will try to write an article, are there any native English speakers who might want to read it trough before publishing?) |
|
Back to top |
|
risto Smarty Rookie
Joined: 26 Apr 2003 Posts: 21 Location: Norway
|
Posted: Tue Aug 19, 2003 5:27 pm Post subject: Problems |
|
|
I'm having some problems recreating what you are explainging. whould you mind posting a link to the source? |
|
Back to top |
|
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Wed Aug 20, 2003 8:33 am Post subject: Re: Problems |
|
|
risto wrote: | I'm having some problems recreating what you are explainging. whould you mind posting a link to the source? |
Link to the source
I made some changes before publishing the source file, because I use a few includes and an autoprepend file.
But the source is more to understand how things work, if you don't understand the principles, do not try The project is not opensource (yet). I'm considering to redesign the database a bit for general purposes, and then create a more modular & robust system.
Some parts of the code ar not so neat (yet). The best parts are path-build function, object-authorisation and the dynamic property assigment.
example (simple) template:
Code: |
{include file="db:habiheader2"}
{* evalled content cannot be empty *}
{if $tContent neq ""}
{eval var=$tContent}
{else}
[Geen inhoud]
{/if}
{include file="db:habifooter2"}
|
|
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Wed Aug 20, 2003 4:37 pm Post subject: |
|
|
Hi Mocean.
Thank-you for providing your code! I would love to see you release your code open-source, but until you decide to do that, I *think* you are probably best not providing it at all, especially without a copyright notice and disclaimer. Perhaps someone here can give better advice?
The legal system sucks, because even if all I want to do is code, it sticks its big nose in the way. |
|
Back to top |
|
mocean Smarty Rookie
Joined: 21 May 2003 Posts: 30 Location: The Netherlands
|
Posted: Wed Aug 20, 2003 4:44 pm Post subject: |
|
|
boots wrote: | Hi Mocean.
Thank-you for providing your code! I would love to see you release your code open-source, but until you decide to do that, I *think* you are probably best not providing it at all, especially without a copyright notice and disclaimer. Perhaps someone here can give better advice?
The legal system sucks, because even if all I want to do is code, it sticks its big nose in the way. |
Thanks for the advice, I'll write a disclaimer and some kind of copyright notice.
I think people cannot use the code without a proper understanding of the system. I adapted a significant part of the code, before creating the source file, because my website is not as general as the presented code and system.
Furthermore, the main part of the system is the CMS back-end, which is much more complicated then the parse-script. |
|
Back to top |
|
risto Smarty Rookie
Joined: 26 Apr 2003 Posts: 21 Location: Norway
|
Posted: Thu Aug 21, 2003 8:02 am Post subject: Relations |
|
|
What about moving the relation to a ProperiesRelation table under Property Types?
I think this would be more in line with the rest of what you are dooing! Is it a boot idea? |
|
Back to top |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|