OK, let me try to clarify this issue a bit. I know Akshay understands the concept as we have talked about this for about a week before he even started this project but i guess he is not using the right terms for the message to come across.
Basically what you're asking is "Why use native MW functionality instead of custom DB objects to store data". You might not be asking this but if you would have tried to understand Akshay's concept and if you'd go trough the code and instead of looking for spacing issues took a moment to look at the logic, you'd see this is what you're asking.
And here's my anwser:
1. forward compatibility (upgradability). If your code uses very narrow link to core you need to maintain that link throughout the native code upgrades. By using native concepts of storing and accessing data in the first place your code gets upgraded for you when the native code upgrades. This extension is using a lot of of such basic concepts that can't change radically in a short time without breaking a lot of other extensions out there. If we'd use DB we'd first have to make sure our DB is abstracted and then maintain compatibility when DB schema and it's abstraction evolves. We'd also have to make sure our code is able to install and upgrade using mw installer principles which would mean yet another additional task.
2. core MW functionality. This extension is in fact a way of linking individual pieces of data (in our case articles about a conference, about events, about locations, about people) into one structure, but while still keeping them what they are: an article. We are applying properties to articles that define their purpose and position in this structure and for that we're using page_props table as these are just that ... page properties. As page_props are a in a sense volatile data, as they get rebuilt every time a page gets parsed so the simplest way to achieve concurrency of these properties over page rebuilds is to make sure that they get recreated by the core itself along with other properties and this is done by using a parser tag. There is still some work to be done, to enable editors to do some inline editing of these tags by masking them and by using alternative editor hook principles. But to link back to the question at hand, my counter-question would be "why reinvent core mw functionality by using custom DB objects for storing page properties?"
3. "cost/effect". The parser tag, besides containing parameters needed to establish the right page_props state for a given page, also has a few additional data chunks, that could possibly be put into custom db objects, however as those chunks of data are small and get used rarely and even then in most cases it is only when doing editing trough administrative dashboard, it would be prudent to ask yourself if you can excuse creating that much additional code for so little effect. I failed to see that effect being enough for the cost and that's why i suggested Akshay to not use custom DB objects just to store that.
This extension is still a beta and as such needs some lovin' to get it from this hackish state to a stable release, but by my accounts the core functionality of it is sane.
And as for standards ... I've mentored Akshay the same way i mentored some people locally and the same way i have mentored all of the interns i've had. I've told them to forget about standards when doing test cases and alpha work, remember they exist when doing beta and try to apply most of them when doing releases as it has proven to be a good strategy for getting fresh solutions and not just crappy copy-pasting of stale snippets to get the work done. And also, just as the code, the standards too need be updated once in a while (and that can't happen if you consider them a law at all times). You might "frown upon" certain things at a given moment, but in the next moment that might just become a logical solution for your problem ... so do take into an account it's "flaws", be skeptical about it's validity ... just don't dismiss it too soon.
And John, as i've told you (or at least tried to tell you) on IRC: before understanding why someone does things in a certain way it's impossible to say if it's good or bad (or even disgusting in your case), so please, try to understand before making conclusions.
LP, Jure
On 08/26/2012 08:04 PM, John Du Hart wrote:
On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughakshay16@gmail.com wrote:
- Parser tags, Magic Words (Variables) and a parser function
parser tags --> <conference>, <page>, <account>, <registration>,<passport>,<author>,<submission>,<event>,<organizer> and
<location>
This is a disgusting way to store data.