Marc Portier wrote:
Sylvain Wallez wrote:
Ralph Goers wrote:
I must admit, I am completely confused. The question was posed earlier as to what the difference between virtual sitemap components and resources are, to which I haven't seen an answer.
It would seem that they are close enough conceptually that having both of them is just going to confuse users even more. Cannot resources be fixed to get rid of some of the shortcomings instead?
The "ratified bug" mentioned by Vadim, is that resources where initially meant to be endpoints only (i.e. must end with a serializer) and implemented as such in the original compiled sitemap engine whereas a bug in the interpreted sitemap engine (that exists for more than 2 years now) allows them to be similar to subroutines and therefore not being limited to being endpoints, since you can return from a resource to the calling point.
So, in this regard, virtual components and resources are very close. IIRC, Stefano once said that virtual components are what resources should have been from the start. So we can consider that once we'll have virtual components, resources will be deprecated.
translating this into 'why would I use them?'
virtual components would thus introduce something which is related to strong-type checking, a resource would be declared (and checked) to function as either a generator, a transformer, a serializer or a complete pipe (Q: will this last thing be something like virtual-read?)
A: FWIW, and IMHO, resources should become this last thing. In main sitemap you do some kind of logic / selectors / etc, and then you have an option to call "resource", which should assemble be complete g / (t)* / s pipeline.
Vadim
today you need to check in the resource's internals to apply it in a correct way to build up a new pipe (of course some personal naming convention helps in that regard)
The important difference also is that virtual components will be inherited by subsitemaps, which is not the case for resources.
which makes sense from usability perspective as well: their contract becomes more rigid, so you can more easily pass them down to users that (potentially) don't have access to those internals
HTH, -marc=
