LampCMS open source XSLT based content management
The first open source CMS that uses browser based XSLT transformation
Wed, 09 Dec 2009 12:37:49 -0600
Some major rewrites taking place.
Fundamentally new features:
User may have more than one email address. Only one of these can be marked as 'default', others are alternative. But these others may be used when posting to mailing lists or when joining mailing lists, etc. Email addresses must still be unique, meaning each email address can still only be used once and that means address can only belong to one user. This also means we can always find user by email address.
Another change: User can have more than one blog. This is very major change because a user will also be able to pick his own sub-domain name for his blog or even change the sub-domain of existing blog, although this is usually a bad idea for the user.
A total rewrite of how user object is instantiated, how it's used, user profile and preferences are not instantiated by default for a logged in user but will be instantiated on demand only when needed.
Options related to user's blog preferences will now be moved to BLOGS table because now the preferences are per-blog and not per-user. A rewrite of edit preferences will also be needed.
A preparation is being made for integrating Google Friend connect with the login system, as well as other authentication method like Facebook connect.
A new type of basic object is being developed and tested. It's more like a new design pattern and it will be called TableRow object. It represents array of data from one table row and will have method to save data back to table if data changes in object.
The user objects will also be called oViewer - to represend the user object of currently logged in user
another one will be oOwner to represent the owner of the blog which is being viewed by viewer.
These are just the terminology and always refer to object of tyle clsUser. Also clsUser object does not always have to be oViewer or oOwner - it can be just a regular oUser when we need to view user data about some user or if we need to edit some user.
The USER table is being modified as well as new tables EMAILS and BLOGS are being added.
There will also be changes to PROFILE and USEROPTION tables - some columns (many of them) will be removed either completely OR moved to BLOGS table.
Another table PROFILE will also be added and it will hold basic profile details like address, phone, job title, etc...
Last change: a User may have multiple avatars. Only one of them will be set a default, so user may be able to easily change them via admin panel but when someone views user details they may see all avatars.
Fundamentally new features:
User may have more than one email address. Only one of these can be marked as 'default', others are alternative. But these others may be used when posting to mailing lists or when joining mailing lists, etc. Email addresses must still be unique, meaning each email address can still only be used once and that means address can only belong to one user. This also means we can always find user by email address.
Another change: User can have more than one blog. This is very major change because a user will also be able to pick his own sub-domain name for his blog or even change the sub-domain of existing blog, although this is usually a bad idea for the user.
A total rewrite of how user object is instantiated, how it's used, user profile and preferences are not instantiated by default for a logged in user but will be instantiated on demand only when needed.
Options related to user's blog preferences will now be moved to BLOGS table because now the preferences are per-blog and not per-user. A rewrite of edit preferences will also be needed.
A preparation is being made for integrating Google Friend connect with the login system, as well as other authentication method like Facebook connect.
A new type of basic object is being developed and tested. It's more like a new design pattern and it will be called TableRow object. It represents array of data from one table row and will have method to save data back to table if data changes in object.
The user objects will also be called oViewer - to represend the user object of currently logged in user
another one will be oOwner to represent the owner of the blog which is being viewed by viewer.
These are just the terminology and always refer to object of tyle clsUser. Also clsUser object does not always have to be oViewer or oOwner - it can be just a regular oUser when we need to view user data about some user or if we need to edit some user.
The USER table is being modified as well as new tables EMAILS and BLOGS are being added.
There will also be changes to PROFILE and USEROPTION tables - some columns (many of them) will be removed either completely OR moved to BLOGS table.
Another table PROFILE will also be added and it will hold basic profile details like address, phone, job title, etc...
Last change: a User may have multiple avatars. Only one of them will be set a default, so user may be able to easily change them via admin panel but when someone views user details they may see all avatars.
0
Sun, 06 Dec 2009 20:16:59 -0600
Decouple user's blog from username
Blog is blog - it's also should be a RESOURCE and as such, have a resourceID. It can extend the RESOURCE class of cause but still, it's a basic RESOURCE.
We can still automatically create a blog for new user based on a username, but we can also ask a user to pick his own blog url - sub-domain OR full domain name.
Some users may even have more than one blog associated with one user account. This would be very helpful for developers that want to create a new blog for every one of their small software packages.
A blog can have a blog entry with download (attachment), then new items may be added as updates, user can add comments, later we may allow adding a forum to a blog, so it will be everything a developer need to maintain his software and have a community.
Some things should be worked-out like should or can we allow changing the sub-domain after the blog is already establised? If user changes sub-domain it's like a big deal because all previously indexed pages will now be unavailable - we return 404 for subdomains we don't have.
Number of blogs per user can and should be determined by the usergroup, at first every user can have just one blog.
Also should a blog that hold a software have special type of RESOURCE_TYPE or not? How can we find a list of free scripts? I guess a blog that is a home of a script must have unique RESOURCE_TYPE.id
This would require a new table to hold some blog related data and we should move BLOG OPTIONS there too, so things like per-page comments, allow comments, etc. will be defined in there.
Blog is blog - it's also should be a RESOURCE and as such, have a resourceID. It can extend the RESOURCE class of cause but still, it's a basic RESOURCE.
We can still automatically create a blog for new user based on a username, but we can also ask a user to pick his own blog url - sub-domain OR full domain name.
Some users may even have more than one blog associated with one user account. This would be very helpful for developers that want to create a new blog for every one of their small software packages.
A blog can have a blog entry with download (attachment), then new items may be added as updates, user can add comments, later we may allow adding a forum to a blog, so it will be everything a developer need to maintain his software and have a community.
Some things should be worked-out like should or can we allow changing the sub-domain after the blog is already establised? If user changes sub-domain it's like a big deal because all previously indexed pages will now be unavailable - we return 404 for subdomains we don't have.
Number of blogs per user can and should be determined by the usergroup, at first every user can have just one blog.
Also should a blog that hold a software have special type of RESOURCE_TYPE or not? How can we find a list of free scripts? I guess a blog that is a home of a script must have unique RESOURCE_TYPE.id
This would require a new table to hold some blog related data and we should move BLOG OPTIONS there too, so things like per-page comments, allow comments, etc. will be defined in there.
0
Sun, 20 Sep 2009 12:41:02 -0500
with embedded image
0
Sun, 20 Sep 2009 12:28:45 -0500
With attachment
here:
0
Sat, 19 Sep 2009 14:33:44 -0500
The submit-by email feature is almost ready.
It already works, just need to add a check to only add link in 'tools' if the MODULE 'by_email' has been installed and required php extensions are present.
Then need to check and possibly fix the handling of attachments - currently it cannot automatically set the xxx flag on attached images if user's blog is rated XXX
It already works, just need to add a check to only add link in 'tools' if the MODULE 'by_email' has been installed and required php extensions are present.
Then need to check and possibly fix the handling of attachments - currently it cannot automatically set the xxx flag on attached images if user's blog is rated XXX
0
