getting screen.width in ftl
Locked
 
|
I am trying to make some ftl code look better on cell phones without
sacrificing the look on desktops. I can remove some non-critical content in the ftl if I knew the screen width was less than a certain value. Can I get screen.width in a bash (groovy) script or in the ftl? Its obviously easy in javascript, but I need to get it in the ftl code. Thanks in advance Skip |
Re: getting screen.width in ftl
Administrator
|
Look at files ending with js.ftl and how they are used
Jacques From: "Skip" <[hidden email]> >I am trying to make some ftl code look better on cell phones without > sacrificing the look on desktops. > > I can remove some non-critical content in the ftl if I knew the screen width > was less than a certain value. Can I get screen.width in a bash (groovy) > script or in the ftl? > > Its obviously easy in javascript, but I need to get it in the ftl code. > > > Thanks in advance > > Skip > |
|
|
Nothing much in these about getting screen width for use in the ftl. Was
expecting that to be in the session of something. Saw some jquery setting of form widths, but I wanted to do this in FTL before the screen html code is rendered. However, got it done with CSS media query like this: @media handheld, only screen and (max-width: 800px){ .notRequired {display: none !important;} } by adding a notRequired class to all the elements I did not want to show on handheld devices. Probably a better solution anyway. Skip -----Original Message----- From: Jacques Le Roux [mailto:[hidden email]] Sent: Tuesday, January 15, 2013 1:59 PM To: [hidden email] Subject: Re: getting screen.width in ftl Look at files ending with js.ftl and how they are used Jacques From: "Skip" <[hidden email]> >I am trying to make some ftl code look better on cell phones without > sacrificing the look on desktops. > > I can remove some non-critical content in the ftl if I knew the screen width > was less than a certain value. Can I get screen.width in a bash (groovy) > script or in the ftl? > > Its obviously easy in javascript, but I need to get it in the ftl code. > > > Thanks in advance > > Skip > |
|
|
Skip,
We have a pretty good way of doing this in our BigFish eCommerce solution. Obviously the entire approach is not applicable for what you are trying to do but you may want to read the guide that we have ... it has some good general pointers that may be useful for you. http://bigfish.salmonllc.com/help/howSetupMobile.htm Best Regards, Nick Rosser [hidden email] O: 516.742.7888 x221 C: 516.901.1720 On 1/15/2013 7:47 PM, Skip wrote: > Nothing much in these about getting screen width for use in the ftl. Was > expecting that to be in the session of something. Saw some jquery setting > of form widths, but I wanted to do this in FTL before the screen html code > is rendered. > > However, got it done with CSS media query like this: > > @media handheld, only screen and (max-width: 800px){ > .notRequired {display: none !important;} > } > > by adding a notRequired class to all the elements I did not want to show on > handheld devices. Probably a better solution anyway. > > Skip > > -----Original Message----- > From: Jacques Le Roux [mailto:[hidden email]] > Sent: Tuesday, January 15, 2013 1:59 PM > To: [hidden email] > Subject: Re: getting screen.width in ftl > > > Look at files ending with js.ftl and how they are used > > Jacques > > From: "Skip"<[hidden email]> >> I am trying to make some ftl code look better on cell phones without >> sacrificing the look on desktops. >> >> I can remove some non-critical content in the ftl if I knew the screen > width >> was less than a certain value. Can I get screen.width in a bash (groovy) >> script or in the ftl? >> >> Its obviously easy in javascript, but I need to get it in the ftl code. >> >> >> Thanks in advance >> >> Skip >> |
|
|
Nick
Thanks for the link. This is essentially what I did except that I did not have any small device specific content. However, what I wanted to do was just not render the content in the ftl to reduce the bandwidth requirements. A considerable amount of the hidden content on small devices were images and it would have been nice to not have it at all. For example: <#assign screenWidth = context.screenWidth?default(2000) /> <#if screenWidth > 499> ... Render some context that might be useful but not required </#if> I am exploring how to do this by having an ajax call that sets the device width into the context and then subsiquent pages can be smarter in their rendering. However, what I have now works much like yours and is sufficient for now. Skip -----Original Message----- From: Nick Rosser [mailto:[hidden email]] Sent: Wednesday, January 16, 2013 12:56 PM To: [hidden email] Subject: Re: getting screen.width in ftl Skip, We have a pretty good way of doing this in our BigFish eCommerce solution. Obviously the entire approach is not applicable for what you are trying to do but you may want to read the guide that we have ... it has some good general pointers that may be useful for you. http://bigfish.salmonllc.com/help/howSetupMobile.htm Best Regards, Nick Rosser [hidden email] O: 516.742.7888 x221 C: 516.901.1720 On 1/15/2013 7:47 PM, Skip wrote: > Nothing much in these about getting screen width for use in the ftl. Was > expecting that to be in the session of something. Saw some jquery setting > of form widths, but I wanted to do this in FTL before the screen html code > is rendered. > > However, got it done with CSS media query like this: > > @media handheld, only screen and (max-width: 800px){ > .notRequired {display: none !important;} > } > > by adding a notRequired class to all the elements I did not want to show > handheld devices. Probably a better solution anyway. > > Skip > > -----Original Message----- > From: Jacques Le Roux [mailto:[hidden email]] > Sent: Tuesday, January 15, 2013 1:59 PM > To: [hidden email] > Subject: Re: getting screen.width in ftl > > > Look at files ending with js.ftl and how they are used > > Jacques > > From: "Skip"<[hidden email]> >> I am trying to make some ftl code look better on cell phones without >> sacrificing the look on desktops. >> >> I can remove some non-critical content in the ftl if I knew the screen > width >> was less than a certain value. Can I get screen.width in a bash (groovy) >> script or in the ftl? >> >> Its obviously easy in javascript, but I need to get it in the ftl code. >> >> >> Thanks in advance >> >> Skip >> |
|
|
good luck!
Best Regards, Nick Rosser [hidden email] O: 516.742.7888 x221 C: 516.901.1720 On 1/16/2013 5:04 PM, Skip wrote: > Nick > > Thanks for the link. This is essentially what I did except that I did not > have any small device specific content. However, what I wanted to do was > just not render the content in the ftl to reduce the bandwidth requirements. > A considerable amount of the hidden content on small devices were images and > it would have been nice to not have it at all. > > For example: > > <#assign screenWidth = context.screenWidth?default(2000) /> > > <#if screenWidth> 499> > ... Render some context that might be useful but not required > </#if> > > I am exploring how to do this by having an ajax call that sets the device > width into the context and then subsiquent pages can be smarter in their > rendering. However, what I have now works much like yours and is sufficient > for now. > > Skip > > > -----Original Message----- > From: Nick Rosser [mailto:[hidden email]] > Sent: Wednesday, January 16, 2013 12:56 PM > To: [hidden email] > Subject: Re: getting screen.width in ftl > > > Skip, > > We have a pretty good way of doing this in our BigFish eCommerce > solution. Obviously the entire approach is not applicable for what you > are trying to do but you may want to read the guide that we have ... it > has some good general pointers that may be useful for you. > > http://bigfish.salmonllc.com/help/howSetupMobile.htm > > Best Regards, > > Nick Rosser > [hidden email] > O: 516.742.7888 x221 > C: 516.901.1720 > > > On 1/15/2013 7:47 PM, Skip wrote: >> Nothing much in these about getting screen width for use in the ftl. Was >> expecting that to be in the session of something. Saw some jquery setting >> of form widths, but I wanted to do this in FTL before the screen html code >> is rendered. >> >> However, got it done with CSS media query like this: >> >> @media handheld, only screen and (max-width: 800px){ >> .notRequired {display: none !important;} >> } >> >> by adding a notRequired class to all the elements I did not want to show > on >> handheld devices. Probably a better solution anyway. >> >> Skip >> >> -----Original Message----- >> From: Jacques Le Roux [mailto:[hidden email]] >> Sent: Tuesday, January 15, 2013 1:59 PM >> To: [hidden email] >> Subject: Re: getting screen.width in ftl >> >> >> Look at files ending with js.ftl and how they are used >> >> Jacques >> >> From: "Skip"<[hidden email]> >>> I am trying to make some ftl code look better on cell phones without >>> sacrificing the look on desktops. >>> >>> I can remove some non-critical content in the ftl if I knew the screen >> width >>> was less than a certain value. Can I get screen.width in a bash (groovy) >>> script or in the ftl? >>> >>> Its obviously easy in javascript, but I need to get it in the ftl code. >>> >>> >>> Thanks in advance >>> >>> Skip >>> |
|
|
what skip mentioned is also
interesting...especially the java script files and pictures make
about 1MB download size for the client. with mobile devices this
is much.
so what I would do is: create a landing page where you just request the kind of device from client (desktop, mobile etc.) or the browser size as nick mentioned. within FTL it is not possible (without Java script), because this is server side. So you have to decide on client side what to do (reason for the landing page). on client side just check with like java script if he uses a mobile device. Than redirect the client to i.ex a subdomain (i.ex. m.domain.tld instead of www.domain.tld). this subdomains just uses other screens, or handle it maybe with properties in screens / session / groovy files. I would create a completely new website for mobile, because most of the time it is completly different, so you need to use other css and js files to reduce the bandwith requirements. you as addition can use the same ftl and groovy files (to have better overview about all files), and just check the session if he is a mobile...than do these checks in groovy and ftl, so at the end of the day you just load parts of these ftl files. for the javascript check build a door to your server session object with an ajax call, which lands on a i.ex. java file which writes attributes to session. with this procedure you can check on serverside the device state and other variables you want to set from client side. kindly robert Mit freundlichen Grüßen Dipl.-Ing. Robert Gan Geschäftsführer Mercon GbR Lückstr. 72/73 D-10317 Berlin (Berlin-Lichtenberg) Email: [hidden email] Tel: +49 (30) 54785060 Fax: +49 (30) 69207219 www.mercon24.deAm 16.01.2013 23:43, schrieb Nick Rosser [via OFBiz]: good luck! |
|
|
sorry for confusing maybe, its late :)
short summary (options which comes to my mind): 1. option: - check with javascript if he is mobile - redirect to another page --> working 2. more elegant option (cause no redirect required) - work with the session object - create a js check if he is mobile - create an ajax connection to your server to write this to the server side session (i.ex. with java on server side). write here the attribute session.setAttribute("isMobile","true") to server session - request with groovy file if he is mobile, and than in ftl just check this with if / else and show different content. thats it I think the second variant is also very comfortable to use for other stuff like setting client configurations like category views etc. So the customer can make individual settings, which will not be lost on other pages / page reloads cause its server side known. hope that helps. |
|
I would not recommend to do anything with Javascript in this case. Responsive design is the most obvious solution and should be the most preferrable.
There are alot of resources available that can show you how to do this properly for the different standard solutions. In adddition to your own solution, you should take care of more than just the max-width:800 sized versions and focus on the different standards that are available. If you were to go the alternative route, using js would not be an option, since you do run js after the initial page load, so js based redirects would only increase the heap. Rather, you could try to get the client from request header and redirect based on that or, preferably, use your actual httpd-server to handle the redirect. With Apache you could use the following: RewriteEngine On RewriteBase / RewriteCond %{HTTP_USER_AGENT} android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge\ |maemo|midp|mmp|opera\ m(ob|in)i|palm(\ os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows\ (ce|phone)|xda|xiino [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a\ wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r\ |s\ )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1\ u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp(\ i|ip)|hs\-c|ht(c(\-|\ |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac(\ |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt(\ |\/)|klon|kpt\ |kwc\-|kyo(c|k)|le(no|xi)|lg(\ g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-|\ |o|v)|zz)|mt(50|p1|v\ )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v\ )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-|\ )|webc|whit|wi(g\ |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-) [NC] RewriteRule ^$ http://m.ilscipio.com [R,L] Alternatively for java, you could use android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge\ |maemo|midp|mmp|opera\ m(ob|in)i|palm(\ os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows\ (ce|phone)|xda|xiino to detect within the request.getHeader("User-Agent"). Regards, Paul |
|
|
As a follow-up:
The solution described in the bigfish link is very limited, so I don't recommend to use or follow it. Basically, with the recommendation described there you are left with a version that won't work on any form of tablet, or mobile devices that are held sideways... I don't want to be too negative about it, since i like seeing resources like that show up, but for doing responsive design, I'd recommend to look into it properly. As said, there are great resources available on the internet for this :) |
|
|
Paul,
My response was just to share our approach/technique. I wasn't expecting Skip, or anyone, to adopt BigFish ... I'm sure he has built out a complete system and to change tack was not the intent. Simply sharing an experience. Anyway, it is an interesting topic and others have made some good points about targeting small devices. We spent some time thinking through this stuff -- what I really like about our approach is that it did not involve any back-end coding changes ... everything is managed in CSS and content. Not perfect, but great for what we're trying to do. And given the approach, it is easily extended to target different sized devices. All the same concepts can be applied, without any back-end changes. Given the base we have we'll be expanding the functionality to be more elegant and flexible over the coming months. The first implementation was to prove our approach/technique and to be able to demo something that works pretty well. When it comes to responsive vs targeted, Robert G made a valid point about having a specific UI for small devices. This solves many problems such as image size (can be controlled), and general page size considerations, with specific functions for a small device user. However, I think we all realize that this is also a lot more work. Responsive has a lot of traction and if done right can target all sorts of small devices. It has the drawback of having resources shown/hidden which can be a burden when using cell service to download pages. Big plus is that it's much easier to implement. I find it interesting trying to define "small device" -- is an iPad really a small device? Or is the regular interface workable? I guess ultimately there is no one right way ... if small device does not play a large role in terms of traffic, but it's important as a strategy, then responsive is perfect. If small device is critical and special features are required to execute the strategy then targeted may be better. Pros and cons for both approaches with many nuances and considerations. Our feeling was the former ... low traffic but important ... so responsive is perfect for us. Best Regards, Nick Rosser [hidden email] O: 516.742.7888 x221 C: 516.901.1720 On 1/17/2013 5:35 AM, Paul Piper wrote: > As a follow-up: > > The solution described in the bigfish link is very limited, so I don't > recommend to use or follow it. Basically, with the recommendation described > there you are left with a version that won't work on any form of tablet, or > mobile devices that are held sideways... I don't want to be too negative > about it, since i like seeing resources like that show up, but for doing > responsive design, I'd recommend to look into it properly. As said, there > are great resources available on the internet for this :) > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/getting-screen-width-in-ftl-tp4638951p4638977.html > Sent from the OFBiz - User mailing list archive at Nabble.com. |
|
|
You are missing the point of my reply, Nick: Responsive is good and the way I also recommend. Your link however, only shows a fraction of what should be done to do it properly and doesn't take care of a lot of the screen sizes, which is why recommend to look elsewhere for the information.
|
|
|
In reply to this post by Paul Piper
Hi Paul,
On Thu, Jan 17, 2013 at 4:48 AM, Paul Piper <[hidden email]> wrote: > I would not recommend to do anything with Javascript in this case. Responsive > design is the most obvious solution and should be the most preferrable. > And my first instinct would have been to use js, perhaps because I have recently been studying the relatively new features in HTML5 that seem intriguing. > There are alot of resources available that can show you how to do this > properly for the different standard solutions. In adddition to your own > solution, you should take care of more than just the max-width:800 sized > versions and focus on the different standards that are available. > Would you care to share your favourite resources? Maybe I picked the wrong search parameters, but when I search the web for this info, the signal to noise ratio is abysmal. :-( > If you were to go the alternative route, using js would not be an option, > since you do run js after the initial page load, so js based redirects would > only increase the heap. Rather, you could try to get the client from request > header and redirect based on that or, preferably, use your actual > httpd-server to handle the redirect. > OK, I can easily get the client from the request header, but, can you shed light on the Apache rewrite rules you show below, in terms suitable for a guy that can write code in a number of programming laguages but for whom this kind of web server administration seems like magic? I have such trouble with the configuration file for Apache's web server that I have yet to figure out how to force all http requests (or all requests for a specific resource) to be resent using https. :-( > With Apache you could use the following: > > RewriteEngine On > RewriteBase / > > RewriteCond %{HTTP_USER_AGENT} > android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge\ > |maemo|midp|mmp|opera\ m(ob|in)i|palm(\ > os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows\ > (ce|phone)|xda|xiino [NC,OR] > RewriteCond %{HTTP_USER_AGENT} > ^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a\ > wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r\ > |s\ > )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1\ > u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp(\ > i|ip)|hs\-c|ht(c(\-|\ |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac(\ > |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt(\ > |\/)|klon|kpt\ |kwc\-|kyo(c|k)|le(no|xi)|lg(\ > g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-|\ > |o|v)|zz)|mt(50|p1|v\ > )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v\ > )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-|\ > )|webc|whit|wi(g\ |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-) > [NC] > RewriteRule ^$ http://m.ilscipio.com [R,L] > > guess I have another question which is, would this mean a separate suite of presentation layer files for each kind of client? Or is there a way to have a single suite of presentation layer files that just adapts to what the client is? Cheers Ted |
|
|
In reply to this post by Paul Piper
I understood your comment. Wasn't that difficult. And agreed with your
point, and mentioned that we were simply sharing an approach/technique with the original query. The group is often used to build information collectively from many different sources, sharing different experiences. If everything has to be exhaustive and show all features then very few folks would participate in this group. Best Regards, Nick Rosser [hidden email] O: 516.742.7888 x221 C: 516.901.1720 On 1/17/2013 11:14 AM, Paul Piper wrote: > You are missing the point of my reply, Nick: Responsive is good and the way I > also recommend. Your link however, only shows a fraction of what should be > done to do it properly and doesn't take care of a lot of the screen sizes, > which is why recommend to look elsewhere for the information. > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/getting-screen-width-in-ftl-tp4638951p4638984.html > Sent from the OFBiz - User mailing list archive at Nabble.com. |
|
|
In reply to this post by Paul Piper
Thanks to everyone for this discussion. Paul, I agree with Teds comment
"the signal to noise ratio is abysmal" when searching for responsive design. I too would love to know your favorite resources. Nick, thanks again for your input. In my view, your approach for simple content (CSS hidding of certain elements) is ideal. Have a look at qz.com to see it in action. I have spent a month or so on the handheld aspect of this project and have yet to find anything compelling for responsive design for data entry forms. Lots of stuff for simple content, but structure form responsive design a different matter. What I do know from experience is this, responsive design is more than just getting the screen to look right on a nearly unlimited number of devices. Bandwidth, at least in the U.S. for handhelds is abysmal. Nearly instantaneous page loads on wired connections take upwards of 30 seconds on a "fast" 3g connection. So, loading a bunch of hidden content, especially images is a bad thing. Having said that, in my exprerience, @media queries are the absolutely best choice when it works. It doesnt work however for complex data entry forms that are used over and over. For example, lets say that you have a form with 16 input fields and maybe a few dropdowns. If you use jquery-mobile style css, this all comes as a long list of entries, one per line on a small device. If you need to keep some of these fields grouped together, it is VERY difficult to achieve like this. Here, javascript was essential for me. Using javascript, I can use ajax to retrieve field labels that are abbreviated for small devices and more informative for desktops. The choice of those labels is made on the server based on screen width. Similiarly, I can use javascript to dynamically set classes based on the screen size. Thanks to all Skip -----Original Message----- From: Paul Piper [mailto:[hidden email]] Sent: Thursday, January 17, 2013 1:48 AM To: [hidden email] Subject: Re: getting screen.width in ftl I would not recommend to do anything with Javascript in this case. Responsive design is the most obvious solution and should be the most preferrable. There are alot of resources available that can show you how to do this properly for the different standard solutions. In adddition to your own solution, you should take care of more than just the max-width:800 sized versions and focus on the different standards that are available. If you were to go the alternative route, using js would not be an option, since you do run js after the initial page load, so js based redirects would only increase the heap. Rather, you could try to get the client from request header and redirect based on that or, preferably, use your actual httpd-server to handle the redirect. With Apache you could use the following: RewriteEngine On RewriteBase / RewriteCond %{HTTP_USER_AGENT} android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(ho ne|od)|iris|kindle|lge\ |maemo|midp|mmp|opera\ m(ob|in)i|palm(\ os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vo dafone|wap|windows\ (ce|phone)|xda|xiino [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a\ wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go )|as(te|us)|attw|au(di|\-m|r\ |s\ )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|c cwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|d ica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os |wa|ze)|fetc|fly(\-|_)|g1\ u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi( pt|ta)|hp(\ i|ip)|hs\-c|ht(c(\-|\ |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac(\ |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi |keji|kgt(\ |\/)|klon|kpt\ |kwc\-|kyo(c|k)|le(no|xi)|lg(\ g|\/(k|l|u)|50|54|e\-|e\/|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|m c(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-|\ |o|v)|zz)|mt(50|p1|v\ )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|o n|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|p g(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\ -a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|s a(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\- |shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v \ )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-m o|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|t e)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\- |\ )|webc|whit|wi(g\ |nc|nw)|wmlb|wonu|x700|xda(\-|2|g)|yas\-|your|zeto|zte\-) [NC] RewriteRule ^$ http://m.ilscipio.com [R,L] Alternatively for java, you could use android|avantgo|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(ho ne|od)|iris|kindle|lge\ |maemo|midp|mmp|opera\ m(ob|in)i|palm(\ os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vo dafone|wap|windows\ (ce|phone)|xda|xiino to detect within the request.getHeader("User-Agent"). Regards, Paul -- View this message in context: http://ofbiz.135035.n4.nabble.com/getting-screen-width-in-ftl-tp4638951p4638 975.html Sent from the OFBiz - User mailing list archive at Nabble.com. |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |