Forum .LRN Q&A: Re: New package: Latest

Collapse
2: Re: New package: Latest (response to 1)
Posted by Dave Bauer on
I like this. I can think of some ways to improve it, #1, it takes alot of clicking to get anything done, not sure how to improve that, maybe have some sort of "summary" for each object.

One additional comment, I see how you just hard-coded the queries for each type of object, that's efficient and probably the best solution for a quick implementation.

Overall, I'd like to see this kind of thing built on top of search, since it provides a consistent interface for retreiving a list of objects.

Or even simpler! Forget all the specific queries, and just use acs_objects, since we have title, and can generate a URL or any object using /o/${object_id}. The only problem with this is restricting the display to "interesting" object types, since there are many internal helper types that you never want to display by themselves.

Anyway, it looks great!

Collapse
4: Re: New package: Latest (response to 2)
Posted by Dave Bauer on
Regarding builidng someting like this on search, until we can get search queries to be alot faster, its difficult to recommend it for a generic query builder, although the concept of having a full text search filter for any list of objects is compelling.
Collapse
8: Re: New package: Latest (response to 2)
Posted by Rocael Hernández Rizzardini on
/o/object_id is working with forums and fs, other object types has to be registered in order to work. A single-all-purpose query is difficult to achieve, specially since you have multiple values that define what has to be shown (like in assessment).
Collapse
9: Re: New package: Latest (response to 8)
Posted by Malte Sussdorff on
Registering more /o/object_id should be something we should strive for the 5.3 release therefore for the bug stomp as well. After all, it should not be too hard to write the callback (will ask Nils to do this for invoices and project-manager, writing a documentation on how to do it).