Re: dynamicdata getitems function

Mikespub wrote:
> >
> I'm afraid that hook integration is one thing where articles still beats
DD,
> mainly because I cheated to get it working there. :-)

I had a feeling this is what I was running into. I took it as more of an
uncompleted work though.

> For DD, I was hoping to use a more generic approach, so that you could
> retrieve the hitcount, ratings, number of comments etc. related to a
> particular item - still based on the enabled hooks for that item, but
without
> needing to "hard-code" the look-ups in hooked tables like I did for
articles.

Yes I liked this.

>
> The hooked property types were one experiment in that direction, but
> didn't provide what I wanted. Next step would be to use an articles-like
> approach, but better... And I'm still stuck on the "better" part there,
> because in some cases you can do a join and retrieve 1 or 2 values,
> in another case you need to count items, and in still another you actually
> need a separate SQL statement to get what you want.
> Plus it should all fit in with the concept of relations within an object
and
> between objects as well, so if you have any ideas on how to tackle that,
> let me know :-)

The more I think about this the more my brain hurts.

> So for your block experiment, you *could* use the respective getitems()
> APIs of hitcount and ratings, and the get_countlist() API for comments,
> etc. after retrieving the items from DD. Or work the other way around and
call
> the respective topitems() APIs first and then retrieve those items from
DD.
>
I am going to play with this a bit. Seems simple it enough. Just stick the
additional  getitem calls in the the foreach loop when forming the array for
the return to the template I take it?

> But that would be cheating just as much... :-)
>
>
> Mike.
> P.S.: I'm glad to see that I'm not the only one who sees the potential
> of replacing the whole articles code with generic DD stuff - it's my
> secret dream for DD too (at least one of them) :-)

Heh, I only stumbled into your dream when you encouraged me with a post to
look at the dyn_example module a while back. The more I looked at it the
better I understood its modularity and its simplicity. I am sure there are
going to be reasons people want to use the "examples" approach and build
from a seperate table. Articles on the other hand does not lend itself well
to either the modularity or simplicity concept. I can't think of a simpler
way to build a module. Create your fields in dd, duplicate dyn_example and
tie it in with your new "OBJECT NOT TABLE" (I struggled to understand what
you were doing here), add your own functions and blocks to do whatever you
want, modify your templates. You can even export your table structures out
of dd and import them into your new module via the init function. I think
you have the right idea. For my own purposes it is the right blend of
functionality with a simple approach that even this aging brain can
understand.

Keep up the great work!
Paul

> _______________________________________________
> Xaraya_knowledge-base mailing list
> [email protected]
> http://lists.xaraya.com/mailman/listinfo/xaraya_knowledge-base