I've just finished my first "real" APEX app but it's looking a bit messy. Is there any way I can renumber the pages so that they're back in order of the application flow?
Copy the page in question and set the new number
Change any references leading to the old page to the new page
Delete the old page
Numbers are arbitrary. Don't go to the hassle of renumbering everything, as you'll need to test all the branches, tabs, breadcrumbs....
The following advice won't help you much with your current application, but I find it useful to plan out the general page numbering in advance.
I start by splitting my application into groups of pages, say, Accounting, Reports and Administration, and then assign 100 (or 1000) pages to each of those groups.
For example:
100 - Accounting (main page)
200 - Reports (main page)
300 - Administration (main page)
Then I assign sub-pages within each group, based on which pages my requirement analysis tells me I will likely need:
100 - Accounting (main page)
110 - List Invoices
120 - Edit Invoice
121 - Edit Invoice - Details Screen
130 - Add new invoice - step 1
131 - Add new invoice - step 2
132 - Add new invoice - step 3
200 - Reports (main page)
300 - Administration (main page)
And so on, you get the idea. Leave some room between the numbers (110, 120, etc.) to be able to add a few pages later.
Of course, it's difficult to plan everything out in advance, so some out-of-place page numbers pages will have to be used after a while, but in my experience a bit of up-front planning makes it much more manageable (and easy to work with).
As Gary suggests, it's better to consider page numbers to be arbitrary.
You could export the application, edit the SQL script with the new page numbers (remembering to search for all locations where a page number is referenced), then re-import the application - and test it thoroughly :) - hopefully you don't have references to the pages in other applications though :)
In Apex 3.2 and later you can put your pages into Groups, which can be useful for sorting the pages out and make it easier to find the page you're interested in.
Step 1: Create a copy of a page(s)
Step 2: And delete your previous page(s).
And Here you go.
But, you'll need to test all the branches, tabs, breadcrumbs etc.
If you are willing to do this, I will suggest you to go through your order of page creation (means, create a copy of first page that you've created at the start of your application). It will help you to get hint which branches,tabs,breadcrumbs needs to be update.
Related
I am working on this app where many pages (8+) are linking to the same page. Every page needs to show correct breadcrumb. Since many pages are linking to the same page, the target page (p5) has a number of breadcrumbs and each breadcrumb has a condition that an application item needs to have a specific value for the parent page.
For example pages 1,2,3,4,6,7 link to page 5. So page 5 has 6 separate breadcrumbs on it where the condition is when parent_page = x where x is the parent page number. So if the user comes from page 1, a correct breadcrumb is selected.
I feel that this is excessive and creates a mess. Also the number of pages that link to page 5 seems to grow. I could create new breadcrumbs for each parent page but I feel that this is wrong and want to find a better way. Can anyone point me in the right direction? how have you handled something like this in the past?
I haven't actually done it, but I remember wanting to at one time. I think you would need to "roll your own" breadcrumbs. You could use an APEX collection to keep track of the user's navigation by "pushing" and "popping" pages on to and off of the APEX collection. Then create a SQL-based list region to display these. You may need to create a bespoke list template to make this list look like breadcrumbs.
Had a similar requirement. Many paths to a single location and keeping the breadcrumbs in sync with the users path was a coding horror story. Finally we decided on not going down that road. The breadcrumb now shows the main path back to the main screen, which might not be the exact path the user followed. So, just a single breadcrumb per page. If you want to go back to the previous page then a "back" or "cancel" button could still do that, but not the breadcrumb.
There are 60 Items in a region showing as a group of 10 rows, 6 Items each.
Initially Items are hidden and each group is getting shown based on a button click.
But the page is taking too long time (10 sec apx) to load the page, same goes for validation also.
Any help here...?
Did you take a look at the debug data ? It shows very clearly what specific section is consuming a lot of time. Once you know what is causing the page to be slow you can start working on a solution.
You can read about debug here: https://docs.oracle.com/database/apex-18.1/HTMDB/utilizing-debug-mode.htm#HTMDB10003
--Koen
Try to uncheck the True or False Actions of DA which Fire on Page load as much as you can.
Page will load fast or we can move few conditions to validation with a generic condition can be another approach of this solution.
I'm trying to understand the best approach to create article items in my sitecore 7.2 project.
Basically I'm considering 2 options:
1 - Create an article as a page;
2 - Create an article as a Site Data Item.
1 - Create article pages under a given page (i.e. My Articles). This way each article would have a specific URL out of the box, easier to understand in Content Authors' point of view;
2 - Have a specific folder (i.e. Article Folder) under Site Data. This way we don't need to have a page for each article - I was thinking to have a single Article page that would render the article fields. However this would require more work in terms of URLs, navigation, etc.
Is there any other ideas? Am I missing something? I was also having a look at Buckets...
Thank you
I'm going to disagree with Marek and recommend you opt for option 2.
Storing your articles in folder under a Data node allows those items to be datasourced. This is the principle Sitecore was built on. You can then surface those articles in a number of interesting ways via Widgets such as Promo Panels, prompting the user to click through to read about the article without duplicating its data and requiring Content Editors to manage data multiple times.
It even supports multiple sites, so the Articles can be used in other sites you may add to your Sitecore instance in the future.
As you state it will require extra work in terms of Urls and Navigation but it can be achieved via Sitecore's Wild Card Item and you an even use a great open sourced Module from Sitecore's Marketplace to complete 90% of the work for you. See links below for more information.
You can still implement Marek's point of applying Presentation Details once on the Standard Values of the Wild Cart Item you create. If you are using Sitecore 7 and above you can store all your articles in a Bucket so if you have lots of articles they are stored and searchable in a meaningful way.
http://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2011/09/wildcards-and-data-driven-urls.aspx
https://marketplace.sitecore.net/en/Modules/Wildcard_module.aspx
In a standard one instance setup the easiest implementation is to create articles as pages.
In Sitecore you want to limit the items in a folder to 100 or less which is best practice to keep the content editors experience optimal.
This then leads you needing a folder structure and a couple options:
Manually maintain a folder structure for your articles. For example articles/year/month/day. This gives your editors the most control over the folder structure and allow them to navigate the articles in a more traditional way via a visible folder structure.
Use a bucket which automatically generates the folder structure and hides this complexity from the content editor. This takes the manual folder creation and maintenance away from the content editor and are automatically generated based on the configuration you set out for your bucket. The folders wont be visible to the content editor so they will be forced to search in the bucket for any articles rather then navigate the folders.
Use the shared source News mover module (https://marketplace.sitecore.net/en/Modules/News_mover.aspx). This takes a different approach to the above. It works via a traditional folder structure however it generates folders and moves the item on save based on the date field in the article. So the news mover handles the generation of folders however you will still need to check your not exceeding 100 items per folder again for performance when opening folders with large amounts of items.
With all solutions you must still consider the URLs for your articles as they will include the folder structure by default. This is not always acceptable. I prefer to remove the folder structure from the URL. For this you need to create a custom linkProvider and a custom HttpRequestProcessor. Firstly the linkprovider allows you to ensure the new URL is always created and displayed in your site as you want. Next the HttpRequestProcessor ensures that when navigating to the shortened URL Sitecore recognises it as a valid URL and presents the correct page.
By excluding the folder structure from the URL it also adds the additional benefit that the URL is not dependent on the structure. This means editors can change that folder structure and not need to create redirect items to ensure SEO rankings or users bookmarks are not lost.
The cleaner data model is to use the wildcard approach for the URLs and centralize the storage of articles data in a bucket of datasources. This will give you optimum performance and reuse of the data.
However, this isn't how an author thinks about their website. When they use the system, they tend to navigate to the area where they would view articles and try to create a new one there. Authors tend to think in 'pages', so try to hide whatever data model you are using from them and give them the ability to edit the page with Experience Editor.
Some developers try to optimize too far and forget that the authoring experience is likely the most important piece of the delivered solution. The author doesn't care how efficiently you stored the data, only that they can edit it easily and publish efficiently. Whatever model supports that for your author base is how you should implement it.
My recommendation is a page-based approach where the author creates the URL structure with folders and items, something they understand. Then, if you really need to, you can have the primary article data be a datasource-driven component on the page. The user gets to use all the tools they are familiar with (Experience Editor,preview navigation) but you can still store the raw data in a centralized folder. You could then theoretically swap out the article data using DMS rules, or hide information based on authentication or membership status.
Go with approach 1: article is a page.
Define all your presentation details on Article Page template __Standard Values. All new articles will get them. And you can change some of the presentation details for your chosen articles if you want.
If you know that you'll have lot of articles, think about year/month/day folder structure, e.g. articles/2015/06/12.
Approach 2 doesn't give you anything - you still need to have an item for every article. And as you wrote, it would require additional coding which is not required.
I am trying to do some reporting on page views on a site and the results are being listed like the following:
www.example.com/directory/ - 100 views
www.example.com/directory/?id=123456 - 10 views
www.example.com/directory/?id=987654 - 5 views
What filter do I need to create to views the results as:
www.example.com/directory/ - 100 views
www.example.com/directory/?id=* - 15 views
Thanks in advance
Yes, getting historical grouped together is going to mean using something like Google Docs, Excel, Tableau Software, Analytics Canvas, etc.
Moving forward...
One of the simplest ways of keeping things grouped in GA is to set up an advanced profile filter. You'll want to use this with a new profile; keeping a "raw" or "empty" profile is highly advisable for when you actually want to look at those individual URLs.
That said, here's a filter pattern that should work for you:
Go to Admin > Filters (under the View Column)
+ New Filter > Create new Filter > Name it
Filter Type = Custom filter > Advanced
Here's the pattern:
Field A: www\.example\.com\/directory\/\?id=.+
Output To: www\.example\.com\/directory\/\?id=\*
Another way to aggregate the same URI with multiple query strings is to change the primary dimension to 'Page Title' under Behavior > Site Content > All Pages.
The best way to do this for your historical data is unfortunately in an excel pivot table. You can get in in the UI, but only by creating a custom report and searching for very specific directories.
Check out the documentation on excluding query strings in your GA profile. Maybe create a new profile and write an advanced rule to rewrite all "id" pages to "/directory/product-page".
A totally different approach is to use custom variables or custom dimensions and to stop looking in the normal "Behavior" reports section (used to be called "Content" in GA) – custom dims are available using Google Analytics Universal Analytics only, which means starting a new web property and possibly running both code snippets concurrently (totally safe to do).
Personally I find custom dimensions a bit easier to work with than custom variables, and I generally think that it's a good idea to start exploring the new Google Analytics.
The nice thing about either of these approaches is that you can still keep the full page path date in the same profile as your custom dimension / variables information; it'll stay in the Behavior section where it belongs with all the other page paths.
Where I'm going with this...
You can create a new dimension such as "page type" and then call it "products", "posts", "articles", or whatever these id #s represent in this /directory/; then you can look at metrics across the dimension like pageviews, time on page, etc. by page type.
You can even create other dimensions to help describe them in more detail, such as breaking down blog posts or products into their different categories; i.e. hierarchical dimensions. Once you start using this kind of thing you may wonder what you ever did without it!
I think it's fair that I stop this answer now since it's not about how to set up custom variables or custom dimensions; those links should get you started (it's really not difficult).
Note: You can use php to fill in the dimension information in the GA tracking snippet dynamically based on the page that is being viewed (again, that's another question).
Say I have a website that has 100 products. Then this is filtered down to 5 sections containing 20 products each. If you were in one of the sections that contained 20 products (e.g. toys), what would be the optimal method to display only 5 toys per page. At the bottom of the list would be next/previous buttons to show the next/previous set of 5 toys.
A better analogy would be google search. There are millions of results but only ~10 are shown at a given time.
So right now I'm using google app engine (python) and django templates. One way I thought of to remedy this problem would be making all the query results go into a div which could then be modified through javascript to give a similar effect. However, if someone were to click their browser's back button, they wouldn't go where they originally came from.
Thanks in advance. Any help would be useful...I don't know what this technique is called so google hasn't been really useful :(
Edit: based on responses, I found my question was solved here: How to use cursor() for pagination?
Look into query cursors. Thay are made to be serialized and sent to client, to be used in creating "next" and "previous" paging requests.
NOTE: don't use offset on queries. This can be VERY expensive, as it actually fetches (and charges) all entities up to offset+limit position, but returns to application only limit results.
I'm not sure that putting all the results as hidden content in the HTML and manipulating it using JS is a very good idea if you might have a large result set (think about what happened if Google used this approach). There's also the back functionality issue that you've mentioned.
So, as for querying a wanted "results page" each time, I think the Google's GQL Reference might help you, take a look specifically at the LIMIT clause, it can help you create the paging mechanism you're looking for by supplying it with the number of items-per-page you want as "count" and the numbers of items-previously-viewed as "offset" (0 at first call).
As for displaying, I think that the Google Images / Facebook News Feed approach might also be interesting to think about (loading on scroll instead of paging), but that's a matter of your personal choice :)
Hope this helps, good luck!
EDIT: After reading Peter's answer, I found it much more efficient to use cursors for pagination, a good reference is given in his answer.