We have templates that use autoslot. The auto slot are currently added to the Contained Slots field of the template. Is it OK if we were to remove those autoslots from the contained slots field of the template, and still continue to use those autoslots in our template code?
I believe we have the contained slots mainly for the slots to appear in the content editor, and since autoslot do not need to appear in the content editor, so it should be OK.
Opinion??
Yes, you can do that. See: http://forum.percussion.com/showthread.php?480-Automated-Slots-and-Publishing&highlight=autoslot
Thanks Jitendra…
So basically that means there is no value to add an auto slot being used in the template to the list of contained slots in the template. Is this correct to say??
Another thing:
Once I removed the autoslot from the contained list, it drastically brought down the number of items being published in the incremental publish.
The value of adding the autoslot to a template is so that it will be published out on every incremental. If you expect there to be a lot of changes every time (or a lot of times…or you don’t know when the changes will occur) to that content item / type then this would be the way to go. Ie. If you were trying to mimic a blog, then there would be value in having the autoindexer (that would say display the entries) publish out every time. For this example, a person’s post would automatically be updated in the index. In the other scenario, where the autoslot is not in the template, the person would manually need to trigger a publish now (on the autoindexer item) or wait for the full publish of the site in order for the autoindexer page to update.
Of course someone should probably insert a plug for the delivery tier services somewhere in here to help out with the publishing problems…once it gets out of alpha…
Thanks Jitendra…
So basically there is no out of the box way around to have the system setup for the autoindex item pages to get republished only whenever any of its query autoindex snippet item is created or updated. So it is basically an always republish or never republish till the auto index page itself gets republished.
thanks
Manvinder
Manvinder,
That is correct.
It would be cool if published autoquery results were stored in a table and on every incremental it would check the table to see if the results have changed and publish out files accordingly… but that is not an out of the box solution…
[QUOTE=jitendra;20344]Manvinder,
That is correct.
It would be cool if published autoquery results were stored in a table and on every incremental it would check the table to see if the results have changed and publish out files accordingly… but that is not an out of the box solution…[/QUOTE]
+1 on this idea (Added to Ideas doc)
storing results in a table is one solution that I have previously thought about when we have looked at improving this behavior. Unfortunately to really know if anything has really changed you need to fully assemble all the content which has its own overhead and may not improve performance so much. Our current implementation mechanism to do this is to use our delivery tier services DTS. Essentially instead of running the query every page assemble you make the metadata available to the front end and run the query on the access of the page.
Any solution that embeds a user generated query in the page will have these problems, the only way to go backwards in the query and to know what has changed if anything is to run the query and compare it with last time. This would mean that we would have to create a snapshot or hash of all the snippet contents. Changes to the snippet itself can come from many sources and is dependent on the template that we do not have control of.
On the previous post. If you remove the slot from the slots tab this will have the effect that the slot will no longer cause the page to be picked up every time in incremental. This may be a required feature though if you do not care so much that the page is kept up to date. You could change the page type to autoindex if you specifically want them to be published every time.
Steve, could an operation be performed upon saving a content item? Said operation would do an “impact analysis” on relationships to verify if they belong to an auto-index, and if so initiate an update on the cached results?
[QUOTE=sbolton;20346]Our current implementation mechanism to do this is to use our delivery tier services DTS. Essentially instead of running the query every page assemble you make the metadata available to the front end and run the query on the access of the page.[/QUOTE] I’m interested to see how DTS is implemented. Vern seems excited about this tier. From demonstrations DTS relies heavily on JavaScript to perform the metadata request and presentation handling.