I am engaged in a project where I need to show path bread crumbs to the user like
Home (This is linked to home page) >> (page name)
and like
Home >> contacts
and in contacts like
Contacts >> create
Contacts >> edit
etc.
Is there a best practice how to do this in spring without he usage of spring web flow? I am not using spring web flow and simply using the spring MVC.
I'm not sure why you'd have to do this in Spring if you're not using Spring MVC.
Depending on the site's structure and the URL structure, you might want to parse the URL into something readable.
Another option is to have some sort of push/pop mechanism but since browsers have a back button which does not signal the server this is often a recipe for disaster.
I'm not sure there is any universal solution for breadcrumbs. Here are a few variants:
use the URL structure. With spring mvc this is actually a very good option, since it (since 2.5) replies a lot on nice, structured URLs
have each page (view) identify its own path in the breadcrumb (via a request parameter). It's not
place current steps in session. This would break if multiple tabs/windows are used, so you will have to use a windowId.. and essentially roll-out a "crippled" webflow.
This sort of breadcrumbs is sometimes called homeward path navigation.
If you can capture your site layout in XML then an XSL could be used to generate the breadcrumbs. The same XML site layout document could also be used to generate a side navigation menu.
See also: Separating breadcrumb (homeward path) navigation from content using XML/XSL.
Related
I want to get programmatically all pages (or one) where portlet is presented on Webspehe portal. Actualy can't find any information about my issue.
The available SPI really was not designed to work back up the chain like this
you can go from layoutcontrol to portletwindow to portletdefinition to portlet
So the ugly way to do this would be to get the content model, loop over all page types, get the layout model for the page, then get the layout controls, from those get the portlet windows, and then go to portlet definition.
The shorter way is to iterate over a full xmlaccess and parse and build the list that way. I did write a whitepaper on how to get the layout controls on the page ftp://public.dhe.ibm.com/software/dw/lotus/Controller_Model_SPI_Final.pdf
Let's say I am creating a webapp for a library. My base url is http://mylibrary.com. I want to use "pretty" URLs as follows:
http://mylibrary.com/books (list all books)
http://mylibrary.com/books/book1 (details of a particular book)
At present my approach is to create a single page app and use history api to manage the URLs. i.e I load all CSS and JS files when the user visits the home page. From then I just get data from server using AJAX, in JSON format and then create the required HTML using Javascript.
But I have learnt that this is not so good from SEO point of view.If a crawler were to visit http://mylibrary.com/books it will not see booklist at all because AJAX calls would not take place.
My question is what is the other approach to design this kind of app ? Specifically:
Should the server create entire web page and send it to browser? I mean will the response from server include everything from <html> to </html> or only the required parts?
Do programming languages like PHP efficiently manage to send the HTML to clients ? I would rather have the webserver do it ..
It appears to me that in this scenario AJAX would have very little role to play other than may be change minor parts of the page. Is that a correct understanding ? ..and here I was thinking AJAX is the modern way of doing things
A library would have many books.
So the list would be long..
Using ajax allows you to fetch only the part of it the user is trying to read, without having to retrieve the entire list, or navigate by reloading.
so for low bandwidth, and impatient users, ajax is a godsend.
for crawlers that need the entire page to collect data from, not so much..
so really you want to provide different content depending on the visistor.
How to identify web-crawler?
IMHO: Provide the page from php, if the user agent is a robot, provide the list, otherwise provide the fancy ajax based site, that shows only what you want, when you want..
I am using Spring 4 MVC to display serve my web page. I now want to display the same content with different layouts wrapped around the body/content depending on the current HttpServletRequest (e.g. request.getServerName()). This means https://page1.test/page.html will be mapped to the same controller as https://page2.test/page.html and returns the same content depending on the controller logic, but page1.test draws for example a different header and footer.
As far as I know, Spring MVC is not capable of doing this. I am now planing to use Apache Tiles 3 or JSP 2.0 tags to do this. Is there any best practice and how can I do this (Spring Java Config is preferred)?
You should take a read of http://tech.finn.no/2012/07/25/the-ultimate-view-tiles-3/ just to see how far you can push Tiles-3
Indeed it can solve what you're after.
(That blog website has just been migrated from wordpress to github pages so some of the code snippets require horizontal scrolling, we're still cleaning these small formatting issues up so please excuse them)
I'm developing a small data-crunching / visualization app in Sinatra, and am split between two options.
The functionality is that you:
Upload a file to the app.
See a nice visualization of its contents.
Maybe start over with a new file.
So my choices are:
Letting both views (upload and results) be managed by the same template, thus creating a single-page app.
Splitting uploads and the visualization between two pages. You upload a file to '/', then are redirected to that file's URL which displays the results.
Which one is better? The advantage of the first is that I can manage it all within the same page, by passing some local vars between the two views.
On the other hand, the second seems like the more RESTful option - because each uploaded file gets its own URL and can be treated as a resource (more fine-grained control).
So, if you want to provide a RESTful API as well along with the web application, it is good idea to have tow different routes.
If you are planning to have just a web UI, it depends on how much control you want to give to the end-user.
Nothing is wrong with either of the approach. It depends on how much ease you can provide.
I am new in building web apps and just begun learning and setting up Grails. I am planning to build an app which has a flow of 4 to 5 pages. Since HTTP is a stateless protocol, how is the state between the pages maintained usually. I am curious what is the accepted standard here, should I create session scoped objects and use them between pages or keep passing around the values between pages (not sure if it is effective if I have a large number of items on a page). Or instead of using 4 to 5 pages should I just use one page with multiple divs and show/hide based on the user clicks?
I think using domain objects in Grails would help here but I dont have a DB backing the UI and only some webservices which will do the UI actions so I cant use domain objects.
A Grails specific solution would be good but also wanted to know how this is handled in web development in general.
Without using a DB, there are a few options you could use:
Use POST/GET variables to pass info from page to page.
Use the session to store information.
Use cookies to store information.
Using POST/GET is usually best if you just have one page "talking" to one other page (e.g. submission of a form). If you have a bunch of data that will be shared by several pages, the best way to do it would probably be to put them in the session. If you need those values to stick around after the user leaves your site and comes back later, then you might want to use cookies.
You may want to look into WebFlow (Spring WebFlow) in Grails. I find it helpful in wizard like or shopping cart like applications where you want to hold on to the data between a group of pages (ie: Page 1, Page 2... Page 4) and then at the end submit the data somewhere etc.