Zikula Community

• kylegio
  
  

  • Rank: Softmore
  • Registered: Sep 30, 2008
  • Last visit: May 29, 2010
  • Posts: 201

  Posted: Dec 25, 2009 - 09:13 PM

  I haven't been active around here in 6+ months because i decided that to further my knowledge of php/databases/cms development i would like to persue development on my own CMS tailored to the needs of some websites i had been meaning to develop for the longes time, i think this was a great choice for me because i have learned a ton, experienced many of the problems and setbacks that any project of considerable magnitude faces and have dealt with them in my own way.
  there is one thing that i came up with to solve a problem i was having and i think zikula could greatly benefit by implementing a similar solution. i realize that in projects like zikula the goal is to outsource as much as possible so that the core can be focused on by the primary developers but i would like people to offer feedback and thoughs on the idea, it could help me with my work and potentially zikula as well.
  
  while programming my own project i used a design concept which largely resembles zikula in its modular design but pulls in concepts i have seen from other projects as well, i ran into the issue that sometimes a module or a function would return an error, we have all seen how zikula handles an error. if you are logged in as an administrator the error and associated information is rendered at the top of the page..etc.
  
  however sometimes it is needful for other users/administrators to be made aware of the error. when i first tackled the problem of error reporting if an error was thrown in my code the associated information was stored in the session, then upon rendering the next page the errors would be rendered at the top of the main content area. the errors would then be removed from the session so they would not be seen every page thereafter.
  
  while this worked well it did not offer the ability for users who may be affected by the error to be notified, i then designed as part of the core for my project an event notifier. the way this would work is when an error was thrown the error would be stored in the database along with the users tho whom it pertains.
  
  next time any of those users accessed a page the system would realize that there was an event which was relevant to them and it would post this error at the top of the main content, so far this only differs from the method using the session by the simple fact that others could be made aware of the error even if they were not the ones who caused it.
  
  the real benefit however was that the error could be made to persist until the user "ok"'d the error.
  for an example consider if there is an error thrown by a module because required settings are not valid or not set at all. when a user with access to this module tries to do something an error is thrown and they see it at the top of the page in a little red box. now they navigate to a part of the site which is not affected by the error, that error message is now gone. but with my method the error would persist to be shown until the user clicked "ok" for that error. maybe all administrators should be made aware that the error occurred, this does not happen with the traditional style error. with the method i implemented however the error would be shown for every administrator, once one has clicked "ok" then they would not see that error again, but the administrators who have not yet clicked "ok" will still see that error.
  
  the beauty of the system is that it is not simply for displaying errors, but any type of event. perhaps there is a change to the terms of usage for the website, you could say that event is global to all registered users. all users would then be made aware of the event upon their next page rendered.
  
  i had used a function which i named registerEvent and could be called from any module or the core itself, some of the options which could be set when regestering an event was the type of event (error, success, update...etc) who it pertains to (single user, multiple users, entire user groups), the requirement to ok the event before continuing to load any pages (meaning if this is set to true, a user who is effected by the event (lets say a change to the terms of usage) will not be able to load any content until they have ok'd the event), an expiry date for the event... stuff like that.
  
  the events were stored in the database with a structure kind of similar to this
  ID || type || module || info || date || ok_required || okd || user || group
  
  so the ID would be the primary auto incrementing key for the events
  the type might be error, update, generic ...etc
  the module would be the module which caused the event or core if the core caused the event
  info would be a short description of the event (example "the temporary directory for uploading pictures is unaccesable" or "the following terms of usage have changed")
  date is the date the event was created
  ok_required is boolean if the user is required to ok this event before continuing with any other pages
  ok's is boolean which will be true if the user has ok'd the event and not true before they have
  the user is the user or group of users to which the event is relevant, if every user in the group has to ok the event then the same event is created in the database for each user, if only one user of a group is required to ok the event then the user is the entire group and the second one of them ok's the even it is gone for everyone.
  
  an example of what this would look like in the database for an event
  ID || type || module || info || date || ok_required || okd || user || group
  1 || notification || Dizkus || "The configuration has been updated || 1261820447 || 1 || 0 || NULL || administrators
  
  the above means there is an event of notification that was issued from the dizkus module stating that the configuration has been update, the event was created at time 1261820447, it must be OK'd before anyone of the group 'administrators' is able to load a page, it must be ok'd by only one administrator. the user/group/module fields would be replaced by the id's instead of the actual name of course.
  
  
  
  i hope that is legible to people, i have a hard time explaining myself in text. please if my explanation of what i have done or the usefulness of it is unclear please let me know and i will try to better articulate myself.
  
  criticism/feedback/thoughts all appreciated.

  • 
  •  
• drak
  
  

  • Rank: Software Foundation
  • Registered: Jul 21, 2001
  • Last visit: May 31, 2010
  • Posts: 624

  Posted: Feb 07, 2010 - 11:29 PM

  You might want to take a look at the event listener system in Zikula 1.3.0. This is truly game changing technology because events themselves are encapsulated and therefore decoupled. This allows amazing flexibility.
  
  Drak
  
  --
  Zikula Lead Developer
  Board Member of the Zikula Foundation
  Follow me on twitter.com/zikuladrak

  • 
  •  
• nestormateo
  
  

  • Rank: Team Member
  • Registered: Sep 06, 2006
  • Last visit: May 09, 2010
  • Posts: 2446

  Posted: Feb 08, 2010 - 12:06 AM

  Wow
  I was in holidays when Kyle wrote this but, you should join to the mind-connection here. Drak is heavily working on the new zOO paradigm, and there's an already built EventManager. The ZEvents will be the piece that will let us do anything, personally, I will love to listen ANY event on the core or a module, any kind of event, and perform any postProcess.
  
  I also have some thoughts about the way Errors are handled ATM, but with the OOP focus we may address many things, or PHP5 will do it for us the core itself should be as simpler as possible, but allow to implement things like the Ok'd for custom needs out there.
  
  Greetz!
  
  --
  - Mateo T. -
  Mis principios... son mis fines

  • 
  •  
• drak
  
  

  • Rank: Software Foundation
  • Registered: Jul 21, 2001
  • Last visit: May 31, 2010
  • Posts: 624

  Posted: Feb 08, 2010 - 01:26 AM

  One key difference now we are PHP5 only of course is we can use Exceptions which will also greatly smooth the error handling process.
  
  Drak
  
  --
  Zikula Lead Developer
  Board Member of the Zikula Foundation
  Follow me on twitter.com/zikuladrak

  • 
  •  
•  
•  

Users on-line

• rgasch

This list is based on users active over the last 60 minutes.