I'd like to see:
- Enable flawless rendering in all browsers
But I don't think I am going to get that one. Otherwise, what you have
listed would be my list as well (that's what I usually do manually when
doing UI development).
-Gary
Eric Dalquist wrote:
Are there any other settings you'd like to see toggled in a "UI Dev
Mode"?
Gary Thompson wrote:
Can I +10 that idea? That would be fantastic.
There are some workable means to get into a "groove" with the uPortal
environment for UI development, but (as with all the Web) the UI
layer is becoming more complex. Having an easy means to tell uPortal
"I'm doing UI development" would be most beneficial.
-Gary
Eric Dalquist wrote:
I think this is a great idea. One thing I'd like to see along with
this work is figuring out a UI developer mode for the portal. This
would likely need to be a configuration property somewhere that is
set before the portal is deployed. It would need to control the
following:
- Use full JS/CSS files, no minification or aggregation.
- Disable all JS/CSS/Image caching
- Disable rendering pipeline caching
- Enable logging of pipeline XSL output
Not sure exactly how one configuration change would do all of that
but it sure seems like a common need for uPortal deployers.
-Eric
Jen Bourey wrote:
Hello all,
I wanted to open up discussion about our options for decreasing the
number of HTTP requests for CSS stylesheets in the uPortal 3.1
branch. Currently the portal's skins generally import some shared
default resources from the new ResourceServingWebapp and from the
theme's common area. These resources include the jQuery UI default
theme, the Fluid Skinning System (FSS)'s standard resources, and a
base uPortal-specific layout.css file. The skin then overrides and
adds to these more general CSS styles, generally through including
several more stylesheets.
While I think the above works well from a development standpoint,
we currently have 14 HTTP requests for CSS stylesheets just for the
base uPortal content (i.e., this count doesn't include any
stylesheets for portlets present on the page). I'd really like to
get this number down as much as we can, while making sure we have a
skin organization that's reasonable to work with.
My current proposal is that we leave the existing structure as is,
but make use of the maven yui-compressor plugin to aggregate the
required files at build time. This would allow us to continue to
have separate, appropriately named files, but only require the
user's browser to download one or two CSS file per skin. For
example, we might create aggregated files as follows:
<aggregations>
<!-- Create the shared Fluid Skinning System stylesheet -->
<aggregation>
<output>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.fss.min.css</output>
<includes>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.reset.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.layout.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/fluid.text.min.css</include>
</includes>
</aggregation>
<!-- Create the uPortal3 skin stylesheet -->
<aggregation>
<output>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3.min.css</output>
<includes>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/print.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/common/css/layout.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jsr168_portlet_spec.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/jquery.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/fluid.theme.uportal3.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_portlet_content.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_ie6override.min.css</include>
<include>${project.build.directory}/${project.build.finalName}/media/skins/universality/uportal3/uportal3_legacy.min.css</include>
</includes>
</aggregation>
<!-- More skins here . . . -->
</aggregations>
One disadvantage of this approach is that it would likely be less
transparent to adopters how the CSS is being assembled. I'd
imagine that we'd at least want to have a README file in the
skins/uportal3 directory that commented on the approach.
Thoughts?
- Jen
--
Jen Bourey
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
eric.dalqu...@doit.wisc.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
