Kees Jongenburger wrote:
> Especially when it leads to 'OR' queries though. This should not happen
> in a clear cloud model, and it is advicable to explicitely avoid it
> using 'searchdirs' otherwise. But still, the extra 'depth' of the query
> is sometimes undesirable. We agree on that :-)
still, most queries in a typical mmbase application are very cachable,
and should be cached. Allso, normally query execution time should stay
below 10 - 15 millisecs, or else you have trouble with your indexes, or
with your queries (or you are stuck with some totally useless database
inheritance scheme :-) ). Presently i don't feel query times to be an
actual problem (unlike update times).
Is the caching framework ready to do stuff like forums?
well, the idear is that you can easily write your own custom application
-specific release strategy. I often used the forum as an example.
If you have forumthreads with forummessages, the usual problem is that
when a message is posted in a thread, all the queries that fetch
messages from any thread will be flushed.
For this you would write a release strategy that, when a relation is
created between a forum message and a forum thread, would:
1 get the tread of the 'new' message.
2 get the thread of the query examined.
3 if they match, flush the query, otherwise no.
you don't have to worry about the message node being committed. As a
rule multilevel queries are no longer flushed on commit of a node (it
has no relations yet, so for multilevel queries it get's interesting
when a relation is created)
so, i guess, the answer would be yes
ernst
This is particularly unfortunate becouse mmbase nodes can not be used in
combination with jstl and expression language, as methods such as
node.getStringValue("name") are not supported bij expression language.
This stands in the way of using mmbase for building mvc webapps.
I think it's OK to use taglibs to get the data that needs displaying,
the jsp should just not use request parameters do define what it
should be showing.
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
