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(a)gmail.com> wrote:
6. 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.