Just curious if there is a best practice when wanting to use global variables across an APEX application. Do people use APEX's APPLICATION_ITEMS or just add PAGE_ITEMS to the Global Page (Page 0)? My initial thought is to use APPLICATION_ITEMS since that is their intended purpose, but using Page 0 gets around the small extra step when having to reference an APPLICATION_ITEM from JavaScript.
Any performance issues or potential caveats I may hit either way that I may not be aware of?
The way I see it, Page 0 items are useful if you want to display the same contents on different pages so that you wouldn't have to maintain many items everywhere, but only on Page 0. If you want to use them as "invisible" global variables, you'd then have to hide them using a server-side condition or dynamic action. But, why would you then use Page 0 items? Use application items instead!
Application items are true global variables; they aren't displayed anywhere in the application, but contain values you use wherever you need them. Not that you can't display their values - you can, but that's not the issue we're discussing here.
I haven't noticed any performance issues while using any of these.
Related
I'm creating a multi-step form with pagination that will show a Next and Previous button depending on which step you are on. In order to display the buttons correctly, I need to store the total number of steps in a variable somewhere.
Do I store this in the Request scope e.g. REQUEST.TotalSteps = 5 or Application scope e.g. APPLICATION.TotalSteps = 5? The number of steps will rarely change so I'm thinking that Application scope is better suited, but I want to minimize the use of RAM because I have a lot of stuff stored in the SESSION scope for each other.
What would be the ideal option?
Depends on how you're gonna be using it really, and what framework you're using, how you're architecting your app and all that sort of thing. You only need the value in memory during the request(s) that need it, so TBH I'd just put it in the variables scope, making sure that the code that sets that variable is loaded for the requests that need it.
You'd not want to put it in session because it's not value specific to the visitor, nor does it have any relevance to the session: it's all just about that form.
Similarly it would not belong in the application scope (well: that has caveats, but given the low level of detail you give us as to how you've built you're app, let's assume this to be the case) because - again - it's not something the entire app needs; just the pages actually interested in how many pages that form has.
If you can give us more information regarding your architecture, I can possibly fine-tune this answer, but based on the info given: this is pretty much how you need to approach it, all things being equal.
The session scope is used to store information for the specific user. The application scope is used to store information that is available to the entire application. The request scope stores information during the course of the request. You want SESSION scope.
Let's say there exists a presentational component in a project that renders an unordered list (called ListRenderer, perhaps.) We have a couple options of supplying data to any given ListRenderer on a page:
Have a TreeList (or TreeListEx) field on the content item, and have ListRenderer read from it.
Supply a DataSource (or other Parameter) to the ListRenderer via the presentation details.
I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project.
So my solutions tend toward option #2, which gets rid of that problem. It does, however, come with its own bag of questions. Where do I put these various "Lists" for a given ListRenderer to use? To maximize reuse and sharing, I usually create a components directory near the site root that contains all these types of things, if I predict the Lists will be shared. This seems less findable and harder to use for the content author, who suddenly have no idea where the source for their ListRenderer is unless they know how to crack open the presentation details (which is slightly advanced for my average user).
If I feel like Lists won't be shared, and are very specific to the page, I'll put them directly underneath the item in question. This has a tendency to muddle up the content tree, though, and any dynamically generated navigation sublayout then has to check for whether or not an item is an actual page before it generates the link to it. The more I work in Sitecore, the less I use this approach, but it seems easier for the content author. There is much easier access to information when you use this approach.
Is there any industry-accepted way of approaching this problem? It happens in projects all the time, and in my head I struggle to balance technical and content authorship concerns in situations like these.
Great question. I've used all the techniques you mentioned, depending on the audience and specifics of the project. The problem is that, as with all things Sitecore, they are all valid ways of achieving the same goal and you will struggle to find one answer that will work in every situation.
I almost always use #2 as well, but some content author retraining maybe necessary and make sure you add in restrictions to what the content author is able to select as a target. I have (within the same project) structured the items near the root (in a shared content folder) and under the item in question, depending on what I felt would provide the best context.
Also, if other child pages would exist below the item as well as the list items, then I would put the list items in a separate folder (with a common "list items" icon") and re-order it to be the first item for separation and clarity.
If you want to use any kind of personalization and DMS then you will need the ability to switch out the datasource anyway so you shouldn't hard code locations.
You might also (if you have not already) want to consider using:
Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- Useful if you need to restructure your content at a later date
Queryable Datasource Locations
- Useful for multi-site situations when you need to make clones, or setting as the default datasource value in Standard Values when the lists are directly below the item but gives you the flexibility to change it.
I prefer using querable datasources personally, I find the xpath syntax more logical.
As Mark has commented, there is no real industry standard.
I feel like this is something that needs improvement.
Especially when you are using the DataSource option, things become less transparent to the editors and as the size of the site grows, so does the complexity.
All I can tell you is how I would do it, which is most likely much like how you are doing it.
1) For overview pages like news, events and faq items, I will put the items underneath the overview item and use the NewsMover shared source module to auto-create a hierarchy.
2) I will create a Global site that contains items that are shared across sites or pages. DataSource items for components will be put in here.
3) For components that are present on the standard values, I will add a list field to the template (for example, when you display related items on a content page)
Most often it's a logical choice and sometimes it's just a matter of taste.
I'd like to add that I've written a blog post on how to have datasource items created automatically for components that are set on standard values. That might help you if you are using those.
Edit:
"I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project."
Today I've blogged about a method of hiding fields and sections in the content editor if there is no sublayout set on the item that requires those fields, which helps to prevent the mess of having a lot of unused fields on your items.
We are looking to enable caching in Sitecore 6 on a specific page, however, this page has an image set based on a random value - and as such, we actually need to cache each individually rendered page so that we can keep this "random" image.
Any suggestions? I figured that we would need to use sublayout params, but can not see how I can set this in the code behind to influence the caching behaviour.
Any way of directly manipulating the cache entry?
Regards,
Andy
Create an outer sublayout defined in Sitecore, e.g. MyComponent. In the code for that, statically bind an inner sublayout, eg. MyComponentInner and in the C# of the former, set the VaryByParms value to be a random number.
I am looking to return a random number between 0 and 4 in a Django view, which is repeatedly called. The number is limited in that it can't be the same as the number that was called previously. It would be fine if the number loops rather than being random, it just can't be the same as what was returned before.
I tried using a variable outside of the view, and incrementing it within the function, but that wouldn't save between each call to the view.
I hope that explanation works, I am brand new to Django.
What you are looking for are sessions.
Using sessions in django: http://docs.djangoproject.com/en/dev/topics/http/sessions/
General explanation of sessions: http://en.wikipedia.org/wiki/Session_(computer_science)
In a nutshell: store things in request.session, use it like any old dictionary.
It isn't clear from your question in what context you want to be sure the value doesn't repeat. For example, do you mean the same browser shouldn't see repeats, or globally, the same URL shouldn't repeat no matter who hits it?
For browsers, use sessions. They are persisted dictionaries identified by browser cookies. If you need it to be global, then you'll have to use the database or a global cache like memcache.
I'm developing a blog application using Django. Currently, the URL /blog/ displays the front page of the blog (the first five posts). Visitors can then browse or "page through" the blog entries. This portion is mapped to /blog/browse/{page}/, where page, of course, is an integer that specifies which "page" of blog entries should be displayed.
It's occurred to me, though, that perhaps the "page number" should be an attribute of the querystring instead (e.g., /blog/browse/?page=2), since the content of the browse pages is not static (i.e., as soon as I add another post, /blog/browse/2/ will have different contents than it had before the post was added). This seems to be the way sites like Stack Overflow and Reddit do things. For example, when paging through questions on Stack Overflow, a "page" attribute is used; likewise, Reddit uses a "count" attribute.
Extending this thinking, I realize that I use the same template to render the contents of both /blog/ and /blog/browse/, so it might even make sense to just use a URL like /blog/?page=2 to page through the contents of the blog.
Any suggestions? Is there a "standard" way of doing this, or at least a "best practice" method to use?
For my money, the best general purpose approach to this issue is to use the django-pagination utility. It's incredibly easy to use and your URLs should have the format you desire.
I prefer to use the GET URL parameter, as in URL?pg=#. It's very common and provides a standard visual clue to users about what is going on. If, for instance, I want to bookmark one of those pages or make an external link, I know without thinking that I can drop the pg parameter to point at the "latest" front-page index. With an embedded #, this isn't as obvious... do I leave off the parameter? Do I always have to set it to 1? Is it a different base URL entirely? To me, having pagination through the GET parameter makes for a slightly more sensible URL, since there's an acceptable default if the parameter is omitted and the parameter doesn't affect the base URL.
Also, while I can't prove it, it gives me the warm fuzzy feeling that Google has a better chance at figuring out the nature of that page's content (i.e. that it is a paginated index into further data, and will potentially update frequently) versus a page # embedded inside the URL, which will be more opaque.
That said, I'd say this is 99% personal preference and I highly doubt there's any real functional difference, so go with whatever is easier for and fits in better with your current way of doing things.
EDIT: Forgot to mention that my opinion is Django specific... I have a few Django apps so I'm relatively familiar with the way they build their URLs, and I still use a "pg" GET parameter with those apps rather than embedding it in the URL directly.
It seems like there are two things going on. A static page, that won't change and can be used for permalinking, like an article, as well as a dynamic page that will update frequently. There is no reason you cannot use both. URL rewriting should allow this to work quite nicely. There's no reason to let the implementation control the interface, there is always at least one way to skin every cat.