Update on YUI 2 to YUI3 progress (Re: Have themes use CDNs for YUI, JQuery, Bootstrap?)

[Glen Mazza <gl...@gmail.com>]

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 <gl...@gmail.com> 
>> 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
>>>
>>>
>

Re: Update on YUI 2 to YUI3 progress (Re: Have themes use CDNs for YUI, JQuery, Bootstrap?)

[Glen Mazza <gl...@gmail.com>]

On 07/12/2014 12:46 PM, Dave wrote:
> That sounds reasonable.
>
> Only other thought is this: don't kill yourself on this task, we don't have
> to switch to YUI3 or eliminate YUI for the Roller 5.1 release. It would be
> nice, but I don't think it is a must have.
>
> - Dave
>

Agreed.  This is lower priority, whatever we can convert before or after 
5.1 would be fine.  (I left my company last month in order to study up 
more on front end technologies, so this is more of a personal learning 
interest for me.)  Philosophically I don't like all-or-nothing on 
upgrades (i.e., we can't deploy 5.1 unless all of XXX is gone) because 
huge blocks of time to be able to accomplish 100% rarely come about, 
with the result that one is rarely able to upgrade anything.

Glen

Re: Update on YUI 2 to YUI3 progress (Re: Have themes use CDNs for YUI, JQuery, Bootstrap?)

[Dave <sn...@gmail.com>]

On Sat, Jul 12, 2014 at 10:56 AM, Glen Mazza <gl...@gmail.com> wrote:

> 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>
>

Sounds like a pain. I can't remember what we had to do to get YUI working
before. I'm pretty sure we just included the YUI2 components that we needed
and not the whole thing.


>
> 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/).
>

I agree. JQuery works great and seems to have a much bigger community & eco
system (possible evidence of that
http://www.google.com/trends/explore#q=jquery,yui,dojo,mootools,scriptaculous
).


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?
>

That sounds reasonable.

Only other thought is this: don't kill yourself on this task, we don't have
to switch to YUI3 or eliminate YUI for the Roller 5.1 release. It would be
nice, but I don't think it is a must have.

- Dave