Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

Smarty with an Object Orientated Website
Goto page Previous  1, 2, 3, 4, 5  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Frameworks
View previous topic :: View next topic  
Author Message
mocean
Smarty Rookie


Joined: 21 May 2003
Posts: 30
Location: The Netherlands

PostPosted: Thu Aug 21, 2003 9:00 am    Post subject: Re: Relations Reply with quote

risto wrote:
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?


The properties are all values with no linking to other objects. And each property has one value.
A relation, however, can connect three objects together, and can also have a value.

One can define of which ObjectType the relation-partners A, B and C may be.

Suppose we have the ObjectType
Photo / City / Photographer
With one relation we can combine the data together, to provide information like 'Photo X is made in city Y by photographer Z'
This would also be possible with 2 relations involving 2 objects.

I use the 'Value' of a parent-child-relation for sorting purposes, to sort children in menu's. You could think of many other possibilities.

Summarizing, I don't think your suggestion is a good one; relations are a very different thing then Properties.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Thu Aug 21, 2003 11:24 am    Post subject: Its starting to work! :) Reply with quote

Its starting to work! Smile
have a look http://vif.ath.cx/objecttype.php
and here http://vif.ath.cx/object.php
I'm hoping this forum will be more active!! Smile
Back to top
View user's profile Send private message
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Thu Aug 21, 2003 1:08 pm    Post subject: OK mocean Reply with quote

I agree Very Happy , now im starting to understand what you are intending for the relations!.
Back to top
View user's profile Send private message
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Thu Aug 21, 2003 8:41 pm    Post subject: relation coming Reply with quote

risto wrote:
http://vif.ath.cx/ooclass.php
This page handles 1 relations involving 2 objects. child Objects.
I created a template that integrats domCollapse.js, a nice little JavaScript so I can collapse related objects and Properties. I think it makes sence to represent Objects in this fashion! It gives the viewer an understanding of the consept mocean led us all to!

Man your database design is so cooll!
People this is truly flexible, try it.

Razz Very Happy
Back to top
View user's profile Send private message
mocean
Smarty Rookie


Joined: 21 May 2003
Posts: 30
Location: The Netherlands

PostPosted: Fri Aug 22, 2003 7:13 am    Post subject: Re: relation coming Reply with quote

risto wrote:
http://vif.ath.cx/ooclass.php
This page handles 1 relations involving 2 objects. child Objects.
I created a template that integrats domCollapse.js, a nice little JavaScript so I can collapse related objects and Properties. I think it makes sence to represent Objects in this fashion! It gives the viewer an understanding of the consept mocean led us all to!

Man your database design is so cooll!
People this is truly flexible, try it.

Razz Very Happy

It's a good representation of the model!

Consider the following: If you are absolutely sure a certain property will be used exactly one time for every object in jour database (for example: creationdate, visits), then you can consider adding it to the Objects table, there is no need to make it more complicated to define such properties trough the property-tables.
_________________
Visit My Smarty Enabled Website (Dutch Only) at www.habiforum.nl
and read how it works.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Fri Aug 22, 2003 8:25 am    Post subject: hmm.. yes! Reply with quote

hmmmmm......? .....your right!

OK maby Ill have a look! just wont to work on forms for a bit now. Man this is looking good! Very Happy You are a genius!!

this DB modle is so versetile!!!! love it.

Forms cumoing up next


one more thing. I see the relations are connected to Object IDs. What about conecting them to Object types? They will work more as standards then right?
Back to top
View user's profile Send private message
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Fri Aug 22, 2003 8:35 am    Post subject: form field typess Reply with quote

mocean, another Item on my list.... what about adding a field in propety type seting form element types. ie select radio text text area.?

It will under normal sercomstances always be the same. Right?
Back to top
View user's profile Send private message
mocean
Smarty Rookie


Joined: 21 May 2003
Posts: 30
Location: The Netherlands

PostPosted: Fri Aug 22, 2003 11:06 am    Post subject: Re: form field typess Reply with quote

risto wrote:
mocean, another Item on my list.... what about adding a field in propety type seting form element types. ie select radio text text area.?

It will under normal sercomstances always be the same. Right?


I use the following rule: I create Date form elements with Fiver pulldown menu's for date & time (then people cannot make mistakes).

For a Char type I use a simple input field, and a textarea for text types. One could consider a table PropertiesInt, but I store them as a char value. I don't see why using a radio with the properties.

For each relation it is best to use some kind of sub-form. Otherwise, many objects have to be loaded in a pulldownbox when adding relations.

In the ObjectProperties table you could add a field 'default value' which allows default values for each propertytype connected with an object. Easy for the CMS.
_________________
Visit My Smarty Enabled Website (Dutch Only) at www.habiforum.nl
and read how it works.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Fri Aug 22, 2003 11:20 am    Post subject: well one thing! Reply with quote

consider this.

If we have an child object called category where you wont to limit peoples options to what already has been inserted, then a select box or radios would be smart.

Ith this case having the relation point to the Object type would also make sence. Then one could add an array with the values to put into the select box. A strict solution for idiots like me! Smile

PS! yes I see that the relations are very usfull for objects, as you see I use them, mut relations from Object types to Objects would be cool!

OR(NOT)???
Back to top
View user's profile Send private message
mocean
Smarty Rookie


Joined: 21 May 2003
Posts: 30
Location: The Netherlands

PostPosted: Fri Aug 22, 2003 11:53 am    Post subject: Re: well one thing! Reply with quote

risto wrote:

[...]
PS! yes I see that the relations are very usfull for objects, as you see I use them, mut relations from Object types to Objects would be cool!

OR(NOT)???


I don't see that.

Suppose you want limited options (categories) for, say a news item. Options for each newsitem must be: local / country / world.

To achieve this, first create a new objecttype called 'category' with properties like 'name' and 'description'.

Then define a relation 'NewsCategorie' to connect them.

In your CMS, you can create a pulldown to add a category to the newsitem.

If you feel you need radio / checkbox / pulldowns instead of text-input, always shift to relations instead of trying to achieve it with some property. The only need of radios for a property I can imagin would be a boolean value (like 'ispublished' or something)
_________________
Visit My Smarty Enabled Website (Dutch Only) at www.habiforum.nl
and read how it works.


Last edited by mocean on Fri Aug 22, 2003 1:58 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
risto
Smarty Rookie


Joined: 26 Apr 2003
Posts: 21
Location: Norway

PostPosted: Fri Aug 22, 2003 1:38 pm    Post subject: Object type too right? Reply with quote

new object and object type then.

Am I right?
Back to top
View user's profile Send private message
mocean
Smarty Rookie


Joined: 21 May 2003
Posts: 30
Location: The Netherlands

PostPosted: Fri Aug 22, 2003 2:26 pm    Post subject: Re: Object type too right? Reply with quote

risto wrote:
new object and object type then.

Am I right?

I mode a small mistake indeed Smile
In fact, you need a new objecttype, a few objects of that type to populate the select box, and a relation to connect the category with a newsitem.

Because the ease of the relations, it is possible to connect a newsitem to multiple categories, and furthermore, you can use the same categories for an agenda, for instance.
_________________
Visit My Smarty Enabled Website (Dutch Only) at www.habiforum.nl
and read how it works.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri Aug 22, 2003 9:15 pm    Post subject: Re: Relations Reply with quote

Excuse me for my briefness, but I have a few comments/questions.

mocean wrote:
I use the 'Value' of a parent-child-relation for sorting purposes, to sort children in menu's. You could think of many other possibilities.

This seems inefficient. Wouldn't a specific table optimized for hierarchical data be better suited here (I'm thinking along the lines of a modified preorder tree traversal)? Especially since hierarchy isn't a ternary relationship and a lot of hierarchical data would endup unnecessarily bloating the relations table.

-

Another idea is to use a small fixed char field (say char(4)) to represent the id in the *Types table. Smaller than the comparable int and realistically, the number of distinct types in a system is relatively small -- for many, char(3) is appropriate. In addition, char fields index well Very Happy. The main reason for this, though, is so that your code can use mnemonic type names instead of magic numbers (db autoincremented ints).

...or an adjacent table that maps tabletype/ids to a char field? Similar code effect, but more joins.

Also, can you explain the choice of AUTO_INCREMENT values in the tables you posted?

--

Any plans to subtype an existing object type?

--

I'm concerned about the objects table. It looks like it has the potential to grow unwieldly large and cause the db to thrash wildly. Are there strategies to partition this table? I would think to use a clustered index on SQL Server/Sybase but I'm not familiar with the equivalent on MySQL or PostgreSQL.

--

Do you have strategies to back object types with actual PHP objects? That is more inline with the way I approach the situation Wink

Thanks in advance and great work!

ps. any objection to me moving this thread to the Frameworks forum?
Back to top
View user's profile Send private message
mocean
Smarty Rookie


Joined: 21 May 2003
Posts: 30
Location: The Netherlands

PostPosted: Sun Aug 24, 2003 8:26 pm    Post subject: Re: Relations Reply with quote

boots wrote:
Excuse me for my briefness, but I have a few comments/questions.

mocean wrote:
I use the 'Value' of a parent-child-relation for sorting purposes, to sort children in menu's. You could think of many other possibilities.

This seems inefficient. Wouldn't a specific table optimized for hierarchical data be better suited here (I'm thinking along the lines of a modified preorder tree traversal)? Especially since hierarchy isn't a ternary relationship and a lot of hierarchical data would endup unnecessarily bloating the relations table.

I've heard of the modified preorder tree traversal system. But in my case, I have objects with multiple parents, and that is not easy to create with this system. Second, I use the sortorder property in only a few cases.

boots wrote:

Another idea is to use a small fixed char field (say char(4)) to represent the id in the *Types table. Smaller than the comparable int and realistically, the number of distinct types in a system is relatively small -- for many, char(3) is appropriate. In addition, char fields index well Very Happy. The main reason for this, though, is so that your code can use mnemonic type names instead of magic numbers (db autoincremented ints).

...or an adjacent table that maps tabletype/ids to a char field? Similar code effect, but more joins.

The number of joins in the SQL part is already quite large, that's not a problem for me.
What exactly means/do mnemonic type names ?

I haven't optimized the database design much yet, because the flexibility in managing the website is my main interest, not database optimalisation.
I try to use Smarty caching to minimize the real SQL load, by triggering the creation of cache files when 'static' pages are saved in the CMS. Only a few pages (search engine for instance) have to be executed entirely on every request.
boots wrote:


Also, can you explain the choice of AUTO_INCREMENT values in the tables you posted?

Every table starts with an autoincrement field calles 'nID' (numeric ID). This ID is used to connect all records to eachother, that's all.

boots wrote:

Any plans to subtype an existing object type?

Do you mean the following? For instance, an object which is called 'address' that consists of street/zippcode/city/country/phone. And using this subtype for objects like person / organisation.

I haven't considered this. It is an option to create an subtype-object, like address, and more subtypes and connect them to a normal object trough relations, but I cannot think of real benefits.

boots wrote:

I'm concerned about the objects table. It looks like it has the potential to grow unwieldly large and cause the db to thrash wildly. Are there strategies to partition this table? I would think to use a clustered index on SQL Server/Sybase but I'm not familiar with the equivalent on MySQL or PostgreSQL.

As stated earlier, the database is not optimized (yet) for performance. I try to minimize Database querying by (Smarty) caching. If you do that, you can optimize the database for flexibility, not performance.
For a website with many dynamic content and less possibilities for caching, a well-designed relational database, with a table for each object, might be better.

boots wrote:

Do you have strategies to back object types with actual PHP objects? That is more inline with the way I approach the situation Wink

Not really. I'm using one parse script to display all different objects. To reuse scripts & HTML I have an object called 'shortcut'. It contains content I use on multiple pages. I created a plugin to display it. For instance, I have an 'searchform' shortcut which displays the searchform. I can access these shortcuts with a Smarty include, like {include file="db:habiheader2"}
My custom template-resource-functions then find the object with that name and display it. I also created some custom plugins, for instance for displaying the news.



boots wrote:


Thanks in advance and great work!

ps. any objection to me moving this thread to the Frameworks forum?

no Smile
_________________
Visit My Smarty Enabled Website (Dutch Only) at www.habiforum.nl
and read how it works.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Sun Aug 24, 2003 10:39 pm    Post subject: Re: Relations Reply with quote

Thanks for your reply, mocean.

mocean wrote:
I've heard of the modified preorder tree traversal system. But in my case, I have objects with multiple parents, and that is not easy to create with this system. Second, I use the sortorder property in only a few cases.
I didn't mean that a replacement for the relations system you had already built, but as an adjunct to only support hierarchical cases (like menus, etc).

mocean wrote:
What exactly means/do mnemonic type names ?
It roughly means short abbreviations that look like the word the represent. Like ADDR for "address". I find it is easier to recall ADDR than arbitrary numbers like 14. Looking at your code, I had noticed several of these "magic numbers" and that is why I made the suggestion Smile

mocean wrote:
boots wrote:
Also, can you explain the choice of AUTO_INCREMENT values in the tables you posted?
Every table starts with an autoincrement field calles 'nID' (numeric ID). This ID is used to connect all records to eachother, that's all.
I'm still unsure as to why those particular values were chosen, but it appears to not be that important Smile

mocean wrote:
boots wrote:
Any plans to subtype an existing object type?
Do you mean the following? For instance, an object which is called 'address' that consists of street/zippcode/city/country/phone. And using this subtype for objects like person / organisation.

I haven't considered this. It is an option to create an subtype-object, like address, and more subtypes and connect them to a normal object trough relations, but I cannot think of real benefits.
Yes, basically. Same idea as extending a base object but the main use would be to add new properties. I was only thinking of it for objectType, though. I guess it just makes the designer's life a little easier and enforces an object type ancestry. Operationally, I think it buys little if anything at all.

mocean wrote:
As stated earlier, the database is not optimized (yet) for performance. I try to minimize Database querying by (Smarty) caching. If you do that, you can optimize the database for flexibility, not performance.
For a website with many dynamic content and less possibilities for caching, a well-designed relational database, with a table for each object, might be better.
Makes sense to me.

mocean wrote:
boots wrote:
Thanks in advance and great work!

ps. any objection to me moving this thread to the Frameworks forum?
no Smile
Welcome to the frameworks forum! Wink
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Frameworks All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 2 of 5

 
Jump to:  
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
Protected by Anti-Spam ACP