Hi Team, having moved about half of the YUI stuff from YUI2 to YUI3, I
can say that the coding is considerably cleaner, it's a nice simpler API
with fewer imports needed. However, it's really designed for non-SSL
CDN use as it significantly bloats the roller-ui folder
(http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/roller-ui/yui3/),
as it uses a separate folder for each JS file instead of nicely allowing
us to store them all in one folder. Unfortunately, as mentioned below,
Yahoo's CDN doesn't support SSL, risking "Warning! non-secure items
being accessed" browser popups if the Roller instance is on HTTPS and we
switch to CDN use to keep the Roller WAR free of all these folders.
I've asked a question about this on Stack Overflow
(http://stackoverflow.com/questions/24713896/efficient-way-to-incorporate-yui3-into-a-java-web-application),
maybe there are ways to simplify embedding YUI3 that I've missed.
YUI 2 is roughly 3.9MB is size, the whole YUI 3 is 34MB and 374
folders. Removing the "coverage" (testing scripts) and "debug" scripts
gets it down to 10MB, probably 4MB if we just keep the "min" files. I
used the YUI configurator (https://yuilibrary.com/yui/configurator/) to
just determine the 75 or so folders that we need (as of now) to just
import those into our code. All this folder complexity results in a
benefit in our JSPs, generally, unlike YUI2, for YUI3, you need only one
script reference (sometimes a few more CSS ones), it will slurp in the
others that it needs:
<script type="text/javascript" src="<s:url
value='/roller-ui/yui3/yui/yui-min.js' />"/> (for CDN
use:<scriptsrc="http://yui.yahooapis.com/3.17.2/build/yui/yui-min.js"/>).
If you need to debug your scripts (say, within Firebug) you can just
change to the CDN debugging JS:
<scriptsrc="http://yui.yahooapis.com/3.17.2/build/yui/yui-debug.js";></script>
Still, I think JQuery should be our first choice when it does what we
want. It has an SSL-supporting CDN, but even if we didn't need it it
takes up far fewer files. For example, the JQuery popup calendar is
just one file (besides images), we add what we need
(http://jqueryui.com/download/) and it creates a custom JS for us,
nicely sitting here:
(http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/roller-ui/scripts/).
What I have left to convert is the Media File Chooser popups on the
Media File View and Edit JSPs. There's one more YUI2 element, the green
"+" menu button present on each image in MediaFileView.jsp, which allows
users to create a blog entry or a podcast from the Media File View page
using the image instead of from the standard EntryAdd.jsp page.
However, the menu button is no longer present in YUI3
(http://yuilibrary.com/yui/docs/node-menunav/) and should probably be
switched over to its JQueryUI equivalent (http://jqueryui.com/button/).
In the interests of getting rid of YUI2, though, I'd like to get rid of
this button entirely now (whether or not it ever gets replaced with
something from JQueryUI). People already have a nearly identical media
file image chooser to embed images on the EntryEdit/EntryAdd JSPs, so
it's redundant allowing them to create blog articles from the Media File
View tab as well (and multiple access paths creates more code
complexity, risk of security holes, user training issues, etc.) The
only thing that would be lost right now is a one-click ability to create
a podcast (pretty rare event anyway), users would need to select the
podcast from the image chooser on the Entry Edit page and copy it to the
EnclosureURL field. Still, IMO that one-click ability should be moved
to the Image Chooser view on the Entry Add/Edit pages anyway. Thoughts?
Sorry for the long post -- lots to report back!
Regards,
Glen
On 07/08/2014 08:15 AM, Glen Mazza wrote:
OK, I guess the Roller UI should be self-contained, i.e., include all
the scripts it needs, no CDN. Assuming a 1-to-100 server bandwidth
ratio between blog writing and blog reading, that's not much of a
server hit for the former to have its needed scripts packaged with
Roller, eliminates a second point of failure, and helps us get
approval from security analysts evaluating Roller for an office
deployment.
For our prepackaged blog themes, either way is fine for me. I think
for 5.1 we'll continue to make the JS/CSS available within Roller for
those who prefer that, independent of whether the themes are coded to
use those files or CDNs. Including the JS/CSS does have a benefit of
allowing people to hack Roller in areas where they might not have wifi
access.
Glen
On 07/08/2014 07:53 AM, Dave wrote:
For themes I think CDN usage is fine. Not sure about the Roller UI
itself
tho.
- Dave
On Mon, Jul 7, 2014 at 10:28 PM, Glen Mazza <[email protected]>
wrote:
Hi team,
I had given a suggested JIRA to Gaurav: https://issues.apache.org/
jira/browse/ROL-2020 for him to factor out the Bootstrap/JQuery into
the
webapps/roller-ui folder so multiple themes can take advantage of
it, i.e.
the user wouldn't need to manually import that library with his theme.
Providing that option would probably still make sense.
I guess though I am behind the times with that suggestion,
apparently our
themes should be using content delivery networks to download the
libraries
instead of the server hosting Roller? YUI would be something like:
http://yui.yahooapis.com/3.17.2/build/cssreset/cssreset-min.css, JQuery
would be http://code.jquery.com/, Bootstrap would be:
http://www.bootstrapcdn.com/.
Apparently the main benefit of using CDN's is that it drops demand
on the
server hosting Roller, making it cheaper for someone to get Roller
hosted
and also making it more attractive for hosting companies to offer
Roller.
However, a drawback is YUI doesn't offer SSL support for
philosophical
reasons (http://yuilibrary.com/yui/docs/tutorials/faq/#does-
yahoos-cdn-support-ssl) That might not be a big deal for us, because
the
blog reader doesn't need SSL as he's not sending any private data
and even
if the blog owner uses SSL to keep his password encrypted on the
wire, not
much else needs to be secure so going to the CDN for a few JavaScript
libraries wouldn't be a big deal.
I guess we'll continue storing the Javascript libraries that the themes
need, but in the future would it be a better design to have the themes
using CDNs? WDYT?
Regards,
Glen
