Menu
▾
▴
openinteract-dev
|
From: Salve J N. <sal...@me...> - 2005-03-03 19:06:08
|
Hi, all!
A couple of us at work were thinking of having a stab at refurbishing
the OI2 templates. We'd like a fresher look and eventually make use of
CSS, DOM+ECMAScript and other kinds of usable goodies.
I've noticed the "Themes" discussion in the OI2Ideas wiki page[1], and
based on it, would like to propose some thoughts for the CSS effort
ahead. I'm sure I haven't considered everything, and hope we can get a
fruitful discussion before we start on 1.99_07... :)
--==o==--
I suggest,
- That things we agree upon are noted somewhere appropriate in the OI2
wiki. If we can't agree, Chris has the privilege to decide Our One True
$PATH. ;-)
- We drop the base_theme package entirely, and implement themes _only_
using CSS. The goal should be that _no_ presentation details are
retrieved from a database (sorry, Teemu ;) ), and that there's only one
authoritative source for information on look and/or theme - namely the
CSS files. All that's necessary to understand the CSS layout must be
made available in an obvious, consistent and easy manner. Doing this
will reduce database/filesystem access, give us a cleaner separation
between data and presentation and improve debugging, system
comprehension, CSS data accessibility, performance and cacheability. We
should try to reduce complexity where we can - keep it simple; Separate
concerns cleanly.
- We create a single set of CSS files that describe the look of all
standard page components and widgets, using CSS classes, ID's and
cascading/inheritance as appropriate. The goal is to have a sensibly-
looking and workable site out-of-the-box, with all style information
easily accessible and/or overrideable.
- That all templates generate valid CSS-friendly XHTML1.0 (where
appropriate, as it's interesting to generate other types of markup too.)
Should the client not understand CSS, the pages must degrade gracefully
(e.g. still be readable/scannable and show the content in a clear and
useful manner.)
- We only allow different "themes" by adding alternative CSS files,
and referring to them in the usual manner from the XHTML documents.
- In the beginning we concentrate on W3C standards compliance. We worry
about browser-compliance issues later.
- There should only be _one_ place for references to style information
in each XHTML page, namely in the <HEAD> section. We allow NO use of
local style attributes in the default templates - we want style
consistency throughout the entire site, and sub-document style
modifications should therefore be avoided.
- Likewise, there should be _no_ ECMAScript/JavaScript inline in the
templates. We'll only allow references to separate .js files so the
browser can load them. If we need to use JavaScipt triggers of some
sort (onmouseover, etc.), we add these from the JavaScript files by
manipulating the DOM tree. This way, we separate document structure
(XHTML) from client-side programs (JavaScript) in a clean and nicely
degradable manner, in addition to improving download speed and
cacheability. For a guide on how to do the DOM manipulation, see the
"Unobtrusive JavaScript"[2] website.
- The stylesheets should be complete (and resulting pages attractive)
enough so that it's not necessary for OI2 applications to override any
of it. But if one _has_ to override something anyway, then it should be
easy to do so.
- If we find the user agent understands the XHTML MIME type
"application/xhtml+xml" (by checking the "Accept:" HTTP header), we
should make sure all XHTML data is transferred as this. (Sadly, not all
browsers support this cleanly, but since we prioritize W3C standard
compliance, we worry about this later.) For a discussion on this topic,
see "Sending XHTML as text/html Considered Harmful"[3].
- We should also make sure all XHTML documents are using UTF-8 as
charset. This may be our first step in making all of OI2 use UTF-8 :).
In order to ease transition to UTF-8, we _may_ want to try to use HTML
entities whenever common eight-bit characters are used (e.g. in I18N msg
files, templates and error messages.)
- Additionally, we should probably have a look at naming conventions.
E.g, all template filenames should have a .tmpl suffix and be in a
namespace. We should try to make it _really_ simple for newcomers to
understand what each file in OI2 is for. A more thorough look into
naming conventions in general may also be in place - see OIN-46[4] for
some initial thoughts regarding this.
- Keep the templates as simple as possible, trying to reduce the
"depth" of INCLUDE and PROCESS calls. A maximum depth of two or three
levels should be strived for.
- If we can avoid breaking the widget API, fine. But when we have good
reasons to break it (e.g. removing the old base_theme-specific stuff),
then we go ahead and break stuff.
- Key structural elements in the generated XHTML should be identified
with the appropriate ID attribute, e.g. the main global menu may look
like this:
<!-- Main menu. See /main.css for style information -->
<ul class="oi2_menu" id="oi2_global_menu">
<li><a href="/user">Users</a></li>
<li><a href="/group">Groups</a></li>
</ul>
<!-- End of main menu -->
This will make it easier to usefult things by manipulating the DOM tree
with JavaScript.
- Other useful features we may want to allow, are the "tabindex",
"accesskey" and "label" attributes in forms, "title" and "alt"
attributes in links and images, metadata elements (e.g. the <meta> and
<link> headers) and how these can be utilized using existing packages
and features in OI2. Further ideas on what to keep in mind can be found
in W3C's "Web Content Accessibility Guidelines" documents[5][6].
- We may also want to explore ways to create menus in a consistent
manner across the entire site, either by using or improving base_box, or
looking at creating a new base_menu package.
--==o==--
In order to do all this, we may need some new functionality:
- A method to allow any package template to specify new CSS files
which should be appended to the existing list of used stylesheets (this
enables the "Cascading" in "Cascading Style Sheets"), e.g.. by using a
method like
[% OI.append_style(
title = "Main style",
css_url = "/css/mypkg/screen.css",
media = "screen" ); %]
..which would generate something similar to the following string:
<link rel="stylesheet" type="text/css"
title="Main style" media="screen"
href="/css/mypkg/screen.css" />
This way, each application has the _possibility_ to extend (or "fix")
specific style issues.
- Likewise, one could get "theme" functionality by allowing for
alternate style sheets
[% OI.append_alternate_style(
title = "High contrast style",
css_url = "/css/mypkg/highcontrast-screen.css",
media = "screen" ); %]
...resulting in:
<link rel="alternate stylesheet" type="text/css"
title="High contrast style" media="screen"
href="/css/mypkg/highcontrast-screen.css" />
- We should also have similar methods for adding external
ECMAScript/JavaScript documents.
[% OI.append_JavaScipt(
src = "/JavaScipt/mypkg/table_sort.js",
defer = "yes" ); %]
...giving:
<script type="text/JavaScipt"
src="/JavaScipt/mypkg/table_sort.js"></script>
- For applications to create application-specific site-general menus in
a globally consistent manner, we may want to be able to "register" one
or more menu items:
[% OI.append_to_action_menu(
TASK = "search",
LINK_KEY = "mypkg.menu_item.searchlink",
LINK_TITLE_KEY = "mypkg.menu_item.searchlink_title",
other_arg = "something useful" ); %]
...which might result in something like this placed in the
application-specific menu:
<li><a href="/mypkg/search?other_arg=something%20useful"
title="Search for my packages">Search</a>
</li>
...or
[% OI.append_to_global_menu(
EXTERNAL = "irc://irc.freenode.net/openinteract",
LINK_KEY = "global.menu.irclink",
LINK_TITLE_KEY = "global.menu.irclink_title",
); %]
...resulting in:
<li><a href="irc://irc.freenode.net/openinteract"
title="Chat with other in the OI2 community!">OI2 Chat</a>
</li>
--==o==--
Finally there are a couple of other things that would be nice to sort out:
- Some way of cleanly managing breadcrumbs, clickpaths and other types
of link-stacks and -queues.
- Likewise standardized a way of telling about program state. (e.g. a
place on the webpage where one always can expect to see "where" in an
application one currently "is", at any given time.)
- Furthermore, I propose we create a branch of the OI2 tree right
after 1.99_06 has been tagged and released, so we have a stable
foundation to work from.
Any thoughts?
- Salve
[1] http://openinteract.org/cgi-bin/twiki/view/OI/OpenInteract2Ideas
[2] http://www.onlinetools.org/articles/unobtrusivejavascript/
[3] http://www.hixie.ch/advocacy/xhtml
[4] http://jira.openinteract.org/browse/OIN-46
[5] http://www.w3.org/TR/WAI-WEBCONTENT/
[6] http://www.w3.org/TR/WCAG20/
--
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute http://met.no/
Information Technology Department / Section for Development
|
|
From: Teemu A. <te...@di...> - 2005-03-05 14:29:38
|
Salve, excellent post and thanks for looking at this. It's an important issue. Current plain HTML interface is so 98'ish. > - We drop the base_theme package entirely, and implement themes _only_ > using CSS. The goal should be that _no_ presentation details are > retrieved from a database (sorry, Teemu ;) ), and that there's only one > authoritative source for information on look and/or theme - namely the > CSS files. All that's necessary to understand the CSS layout must be > made available in an obvious, consistent and easy manner. Doing this > will reduce database/filesystem access, give us a cleaner separation > between data and presentation and improve debugging, system > comprehension, CSS data accessibility, performance and cacheability. We > should try to reduce complexity where we can - keep it simple; Separate > concerns cleanly. Absolutely. This is the path I wanted to go for. The theme provider might want to create its own theme and if there are images and some templates then distributes that as a separate package. But obviously, base_theme is not required. > - We create a single set of CSS files that describe the look of all > standard page components and widgets, using CSS classes, ID's and > cascading/inheritance as appropriate. The goal is to have a sensibly- > looking and workable site out-of-the-box, with all style information > easily accessible and/or overrideable. Modified themes (different color schemes etc) could be implemented with inherited CSS files. That way I could create user specific themes, so the user could select the colors etc. she/he wants and the code generates an inherited CSS file, with only the color definitions in it. > - We only allow different "themes" by adding alternative CSS files, > and referring to them in the usual manner from the XHTML documents. Exactly, my previous point. I guess we need a table: theme_id = ? base_theme_css = ? theme_css = ? media = ? title = ? description = ? Based on that, appropriate links to CSS files coul be generated to <head>. We also might need a mechanism to introduce CSS files for different media types (for example, hiding certain navigational goodies from small screen terminals) and browser types. Our experience is that it's possible to write a single CSS file that is cross-browser compliant from NS4 to latest opera/safari/ie/mozilla, but requires enormous amount of work (several months) to get right if the page is even a little bit more complicated. > - In the beginning we concentrate on W3C standards compliance. We worry > about browser-compliance issues later. w3c compliance with mozilla ;) > - There should only be _one_ place for references to style information > in each XHTML page, namely in the <HEAD> section. We allow NO use of > local style attributes in the default templates - we want style > consistency throughout the entire site, and sub-document style > modifications should therefore be avoided. Most tags generated should include class information for easy styling. > - Likewise, there should be _no_ ECMAScript/JavaScript inline in the > templates. We'll only allow references to separate .js files so the > browser can load them. If we need to use JavaScipt triggers of some > sort (onmouseover, etc.), we add these from the JavaScript files by > manipulating the DOM tree. A reason to include meaningful id properties to most central tags. > - We should also make sure all XHTML documents are using UTF-8 as > charset. This may be our first step in making all of OI2 use UTF-8 :). > In order to ease transition to UTF-8, we _may_ want to try to use HTML > entities whenever common eight-bit characters are used (e.g. in I18N msg > files, templates and error messages.) I've got four thumbs up here. Gettext in the I18N side ;) > - Keep the templates as simple as possible, trying to reduce the > "depth" of INCLUDE and PROCESS calls. A maximum depth of two or three > levels should be strived for. Oh yeah.. Template Toolkit isn't very good at executing multiple levels of INCLUDE/PROCESS. With Dicole we implemented a fairly nice widget framework out of TT templates, resulting in quite a lot of depth. In theory it was great but in practice too slow. We have had to optimize certain parts by adding a partly compiled template for certain heavily used applications which have complex views. > - If we can avoid breaking the widget API, fine. But when we have good > reasons to break it (e.g. removing the old base_theme-specific stuff), > then we go ahead and break stuff. Break, smash and kill it. Basic header, body and footer templates are enough, maybe some other commonly used sections in body can be separated for easier modification/maintenance.. but don't do what I did (widgeting everything) =) > <!-- Main menu. See /main.css for style information --> > <ul class="oi2_menu" id="oi2_global_menu"> > <li><a href="/user">Users</a></li> > <li><a href="/group">Groups</a></li> > </ul> > <!-- End of main menu --> > > This will make it easier to usefult things by manipulating the DOM tree > with JavaScript. Yep. For a menu, use an unordered list. With some included javascript and voodoo CSS you can work out. > - Some way of cleanly managing breadcrumbs, clickpaths and other types > of link-stacks and -queues. Now that we have REST, why not include a breadcrumbs title for each part.. > - Likewise standardized a way of telling about program state. (e.g. a > place on the webpage where one always can expect to see "where" in an > application one currently "is", at any given time.) Sitemap? Easy to generate out of registered applications if they include REST parameters and titles for each.. -- Teemu Arina, CTO Ionstream Oy / Dicole Komeetankuja 4 A 02210 Espoo FINLAND Tel: +358-(0)50 - 555 7636 skype: infe00 Corporate website: http://www.dicole.com FLOSS in education: http://flosse.dicole.org Personal weblog: http://infedelic.blogspot.com "Discover, collaborate, learn." |
|
From: Salve J N. <sal...@me...> - 2005-03-07 14:08:56
|
Teemu Arina wrote: > Salve, > >> - We create a single set of CSS files that describe the look of all >> standard page components and widgets, using CSS classes, ID's and >> cascading/inheritance as appropriate. > > Modified themes (different color schemes etc) could be implemented > with inherited CSS files. That way I could create user specific > themes, so the user could select the colors etc. she/he wants and the > code generates an inherited CSS file, with only the color > definitions in it. If I understand you correctly, you'd like to generate CSS files? (as opposed to generating CSS dynamically per-request.) I was thinking more in the direction of _not_ to generate any CSS _at_all_ - that all CSS files are static. Generating CSS would be useful only for the simplest alterations, like colour schemes, border width and such. CSS is even now such a complex beast, that creating code to generate it would more likely increase total complexity instead of decreasing it. Furthermore, I'm imagining (semi-) dynamic CSS customisations are mostly useful for user-configurable (personal) themes and not much more. I'm having trouble seeing how this kind of feature is enough for the people who would like to make the OI2 UI adhere to their company website profile. The people who like the default layout can probably find the correct CSS file and change colors and looks there, and those who don't most likely won't appreciate the added complexity when they start adding CSS files and changing templates. Personal themes is IMHO simple fluff, mostly to make the "ooh! shiny!" people happy, and not much more. But we _should_ allow OI2 to easily adhere to an established website profile in a company. This can be done easily enough by adding CSS files and/or replacing templates, can it not? >> - We only allow different "themes" by adding alternative CSS files, >> and referring to them in the usual manner from the XHTML >> documents. > > Exactly, my previous point. I guess we need a table: > > theme_id = ? > base_theme_css = ? > theme_css = ? > media = ? > title = ? > description = ? > > Based on that, appropriate links to CSS files coul be generated to > <head>. Hmm... I was thinking more in the direction of having a standard set of CSS files for all pages, and then let each application add stylesheets on it's own, either by using an "append_style"-like method, or perhaps by tweaking a configuration file (e.g. the app's action.ini file). No tables should be needed at all. But that may be short-sighted of me. What are the arguments in favour of having CSS metadata in the database? (other than enabling user customisation?) > We also might need a mechanism to introduce CSS files for different > media types (for example, hiding certain navigational goodies from > small screen terminals) and browser types. Right. The mechanisms I proposed to do this were the "append_style" and "append_alternate_style" methods. > Our experience is that it's possible to write a single CSS file that > is cross-browser compliant from NS4 to latest > opera/safari/ie/mozilla, but requires enormous amount of work > (several months) to get right if the page is even a little bit more > complicated. I actually like the minimalist style OI2 currently has, even if it's not among the prettiest. If we try to keep the layout as simple as it is now (just the content/forms, and the concept of "boxes") I'm sure we can tidy up the look and reduce the number of templates without adding too much new functionality. :) And as long as we KISS, we'll hopefully stay out of the compatibility trap. ;-) >> - Likewise, there should be _no_ ECMAScript/JavaScript inline in >> the templates. We'll only allow references to separate .js files so >> the browser can load them. If we need to use JavaScipt triggers of >> some sort (onmouseover, etc.), we add these from the JavaScript >> files by manipulating the DOM tree. > > A reason to include meaningful id properties to most central tags. Exactly. :) >> - We should also make sure all XHTML documents are using UTF-8 as >> charset. This may be our first step in making all of OI2 use UTF-8 >> :). In order to ease transition to UTF-8, we _may_ want to try to >> use HTML entities whenever common eight-bit characters are used >> (e.g. in I18N msg files, templates and error messages.) > > I've got four thumbs up here. Gettext in the I18N side ;) Gettext vs. Maketext vs. [alternatives] most likely deserves it's own discussion. I'm sure Chris and others have some thoughts about that. :) >> - Keep the templates as simple as possible, trying to reduce the >> "depth" of INCLUDE and PROCESS calls. A maximum depth of two or >> three levels should be strived for. > > Oh yeah.. Template Toolkit isn't very good at executing multiple > levels of INCLUDE/PROCESS. With Dicole we implemented a fairly nice > widget framework out of TT templates, resulting in quite a lot of > depth. In theory it was great but in practice too slow. We have had > to optimize certain parts by adding a partly compiled template for > certain heavily used applications which have complex views. Hm. Yes, I can imagine the templates can become quite slow if we don't take care... Do you have any thoughts and experiences on how to create a good set of templates? At met.no we're thinking about dropping the "forms in tables" paradigm entirely, and replace it with CSS-formatted definition lists, then removing any "single includes" (files that are only included from one template), require all widgets to have a label, and drop the distinction between widgets in rows and plain widgets... In sum, this should reduce complexity and depth significantly. :) We'll show you the code when it's ready. ;-) >> - If we can avoid breaking the widget API, fine. But when we have >> good reasons to break it (e.g. removing the old base_theme-specific >> stuff), then we go ahead and break stuff. > > Break, smash and kill it. Basic header, body and footer templates are > enough, maybe some other commonly used sections in body can be > separated for easier modification/maintenance.. but don't do what I > did (widgeting everything) =) I kind of like the idea of widgets. It lets us do the basic stuff easily while keeping the resulting HTML consistent, and if I need to do things my own way, I still can. What kind of alternatives would you suggest? >> - Likewise standardized a way of telling about program state. (e.g. >> a place on the webpage where one always can expect to see "where" >> in an application one currently "is", at any given time.) > > Sitemap? Easy to generate out of registered applications if they > include REST parameters and titles for each.. That's true. A generated index page would also be useful - perhaps based on keywords gathered with other tools? (e.g. from user-contributed tags with Chris' delicious_tags package, or something automatically gathered using an indexing tool like Plucene?) But with "program state" I was thinking more of Jacob Nielsen's usability heuristics[1] where he suggests lots of relevant things for us. :) - Salve [1] http://useit.com/papers/heuristic/heuristic_list.html -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
|
From: Teemu A. <te...@di...> - 2005-03-07 19:39:33
|
> If I understand you correctly, you'd like to generate CSS files? (as > opposed to generating CSS dynamically per-request.) > > I was thinking more in the direction of _not_ to generate any CSS > _at_all_ - that all CSS files are static. > > Generating CSS would be useful only for the simplest alterations, like > colour schemes, border width and such. CSS is even now such a complex > beast, that creating code to generate it would more likely increase > total complexity instead of decreasing it. Well, I meant that all CSS files are static. Support for introducing additional CSS files that inherit main CSS properties would just prove useful to make a tool that allows personalization of the interface by using a tool that generates a new CSS file for the user. The result is a static file. I'm a big fan of individual customization and this is the simplest and all we need. In our toolset I receive a lot of requests from our users that they want to customize their own space to their liking. It's their space after all and with small steps I can make a tool for them to customize the layout. They don't have to write the CSS their selves. I hate browsing blogger.com and seeing that 95% of people use the same stock themes. Editing the template is too much for most. With a small tool the CSS parameters could be changed and an additional CSS file generated to change some basic properties in the main theme. I bet most would use it. This is what I want OI to support and it isn't too complicated in my opinion. Not at all. Nothing is dynamically generated every time. > This can be done > easily enough by adding CSS files and/or replacing templates, can it not? I need a tool for your granny to customize it for herself. Simple stuff. Most user interfaces have common properties that could be changed at once with inherited CSS files. Requesting her to write a custom CSS file just doesn't cut it ;) > Hmm... I was thinking more in the direction of having a standard set of > CSS files for all pages, and then let each application add stylesheets > on it's own, either by using an "append_style"-like method, or perhaps > by tweaking a configuration file (e.g. the app's action.ini file). No > tables should be needed at all. .ini files are fine, also. You are right. We still need a system wide CSS file, though. server.ini? > But that may be short-sighted of me. What are the arguments in favour of > having CSS metadata in the database? (other than enabling user > customisation?) User customization doesn't need the table, either. I'm not asking OI to implement users custom colors etc. I can do it myself. I ask the framework to support media types to select an appropriate CSS file out of a time based on accessing client and some additional CSS files I would like to use to provide user constomization to themes. It's my problem how those additional CSS files are generated. > I actually like the minimalist style OI2 currently has, even if it's not > among the prettiest. If we try to keep the layout as simple as it is now > (just the content/forms, and the concept of "boxes") I'm sure we can > tidy up the look and reduce the number of templates without adding too > much new functionality. :) Yep. We have gone crazy with our UI in Dicole. I also propose that <table>:s are not used to align stuff on the screen in OI basic theme. Columns can be achieved through other means. > Hm. Yes, I can imagine the templates can become quite slow if we don't > take care... Do you have any thoughts and experiences on how to create a > good set of templates? What comes to my mind is the box model of Mambo (a wacky PHP based CMS). It has footer, header and the body part which is divided into left, right, middle, top and bottom. Then there are some basic interface parts like tables, breadcrumps, tree navigation etc. The nicest thing is you have boxes (similar to OI) that contain all kinds of dynamic data and some UI through which you can decide in what part of the interface they go: right, middle, left etc. In Dicole we went and implemented content of individual boxes in a very detailed way. For example, if you have a table, you have each cell of the table executing INCLUDE/PROCESS of customly requested templates. Those templates might even include more templates etc. It is very flexible and allows nice tricks but you can imagine that a page has easily about 100-200 includes. You want to keep that amount very low per page. We generate forms with this system. We have a table template which could include any custom templates in the cells. So the cells are basically input field templates (values) and simple text templates (keys). Lots of includes, not good. > I kind of like the idea of widgets. It lets us do the basic stuff easily > while keeping the resulting HTML consistent, and if I need to do things > my own way, I still can. > > What kind of alternatives would you suggest? A very specific widget system allows you to write a UI library that operates similarly to something like Perl/TK. You can have containers and all kinds of stuff in them. The UI logic is then written in perl but separated from the business logic. The view, how the widgets are displayed based on the generated data structure is also separated for the interface designer. The drawback is that the designer loses some of the control on how various pages look but well, the result is more consistent and easier to maintain so. So with a web based widget UI toolkit, you basically define various parts your application may have. The most useful part for the UI widget toolkit is obviously the application part itself (excluding page navigation, footers, login boxes etc). Dynamically generating each page in a very detailed widget system is very slow in TT because of hundreds of includes, so this could be optimized by pre-generating applications. Detailed widget systems are to some degree predictable, so: on server startup (or when a single application action is accessed the first time), the UI templates for various application actions/tasks get generated once. The resulting output for each page is a new cached template toolkit template that is able to take in business logic from the application. Server startup will be slow but this way we have only one template include for each application task, problem solved. That's the way I thought I would like to optimize our system but it sure requires a lot of thinking to implement correctly. We will lose some freedom and control in our templates but I think the consistency is worth the effort.. and it would be the coolest UI toolkit for the web ;) When writing a new application for OI, in most cases you don't have to write a single template. Saves a lot of development time. -- Teemu Arina, CTO Ionstream Oy / Dicole Komeetankuja 4 A 02210 Espoo FINLAND Tel: +358-(0)50 - 555 7636 skype: infe00 Corporate website: http://www.dicole.com FLOSS in education blog: http://flosse.dicole.org Personal weblog: http://infedelic.blogspot.com "Discover, collaborate, learn." |
|
From: Salve J N. <sal...@me...> - 2005-03-08 17:09:35
|
Teemu Arina wrote: >> If I understand you correctly, you'd like to generate CSS files? >> (as opposed to generating CSS dynamically per-request.) >> >> I was thinking more in the direction of _not_ to generate any CSS >> _at_all_ - that all CSS files are static. > > I need a tool for your granny to customize it for herself. Simple > stuff. Most user interfaces have common properties that could be > changed at once with inherited CSS files. Requesting her to write a > custom CSS file just doesn't cut it ;) I'm all for a seperate package that can supply this feature, and if you'd like to make it, then you should be able to. :) >> Hmm... I was thinking more in the direction of having a standard >> set of CSS files for all pages, and then let each application add >> stylesheets on it's own, either by using an "append_style"-like >> method, or perhaps by tweaking a configuration file (e.g. the app's >> action.ini file). No tables should be needed at all. > > .ini files are fine, also. You are right. We still need a system wide > CSS file, though. server.ini? System-wide config belongs in server.ini, yes. :) e.g. ==========================8<----------< somewhere in server.ini [stylesheets] main_style_sheet = /main.css main_style_media = screen @,alternate_style_sheet = /print.css,/mobile.css @,alternate_style_media = print,handheld ------------------------------------------------->8============= >> I actually like the minimalist style OI2 currently has, even if >> it's not among the prettiest. If we try to keep the layout as >> simple as it is now (just the content/forms, and the concept of >> "boxes") I'm sure we can tidy up the look and reduce the number of >> templates without adding too much new functionality. :) > > Yep. We have gone crazy with our UI in Dicole. I also propose that > <table>:s are not used to align stuff on the screen in OI basic > theme. Columns can be achieved through other means. Tables are nice for tabular data, though. :) At work we've experimented with structuring forms using only <dl|dt|dd>, <span> and <div>. It looks promising, and we'll try to show what we're up to when things are getting ready. :) >> I kind of like the idea of widgets. It lets us do the basic stuff >> easily while keeping the resulting HTML consistent, and if I need >> to do things my own way, I still can. >> >> What kind of alternatives would you suggest? > > > A very specific widget system allows you to write a UI library that > operates similarly to something like Perl/TK. You can have containers > and all kinds of stuff in them. The UI logic is then written in perl > but separated from the business logic. The view, how the widgets are > displayed based on the generated data structure is also separated for > the interface designer. The drawback is that the designer loses some > of the control on how various pages look but well, the result is more > consistent and easier to maintain so. > > So with a web based widget UI toolkit, you basically define various > parts your application may have. The most useful part for the UI > widget toolkit is obviously the application part itself (excluding > page navigation, footers, login boxes etc). Dynamically generating > each page in a very detailed widget system is very slow in TT because > of hundreds of includes, so this could be optimized by pre-generating > applications. Detailed widget systems are to some degree predictable, > so: on server startup (or when a single application action is > accessed the first time), the UI templates for various application > actions/tasks get generated once. The resulting output for each page > is a new cached template toolkit template that is able to take in > business logic from the application. Server startup will be slow but > this way we have only one template include for each application task, > problem solved. > > That's the way I thought I would like to optimize our system but it > sure requires a lot of thinking to implement correctly. We will lose > some freedom and control in our templates but I think the consistency > is worth the effort.. and it would be the coolest UI toolkit for the > web ;) When writing a new application for OI, in most cases you don't > have to write a single template. Saves a lot of development time. I think I'll have to digest this a little... - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
|
From: Chris W. <ch...@cw...> - 2005-03-08 15:14:09
|
* Teemu Arina (te...@di...) [050305 11:39]: >... > I've got four thumbs up here. Gettext in the I18N side ;) I had a thought about this. From what I understand gettext uses .po files to store its data. These are text files in a particular format. There's a perl module Locale::Maketext::Lexicon [1] that's able to read PO or MO files into Locale::Maketext format, which is what we're using. What if OI2 supported both its native .properties format as well as the PO format? (I'm not sure where the MO format comes from, but if it's easy to support we could throw that in as well.) That would allow you to use existing l10n-editing tools but OI2 to continue to use its existing framework. Is that reasonable/possible? FWIW, I'm also still noodling over the abstract vs concrete message keys and *may* wind up automatically translating all keys in OI2 to concrete. Chris [1] http://search.cpan.org/~autrijus/Locale-Maketext-Lexicon-0.47/ -- Chris Winters (http://www.cwinters.com) Building enterprise-capable snack solutions since 1988 |
|
From: Teemu A. <te...@io...> - 2005-03-08 15:18:28
|
> I had a thought about this. From what I understand gettext uses .po > files to store its data. These are text files in a particular format. > > There's a perl module Locale::Maketext::Lexicon [1] that's able to > read PO or MO files into Locale::Maketext format, which is what we're > using. > > What if OI2 supported both its native .properties format as well as > the PO format? (I'm not sure where the MO format comes from, but if > it's easy to support we could throw that in as well.) That would allow > you to use existing l10n-editing tools but OI2 to continue to use its > existing framework. Is that reasonable/possible? That's exactly what I had in mind. MO is simply compiled PO. You write your stuff in as PO files and those get compiled in some weird MO files. I don't know which is faster, I guess MO is more designed towards C-based applications. You can manipulate and play around with MO files with tools from the GNU gettext toolset. > FWIW, I'm also still noodling over the abstract vs concrete message > keys and *may* wind up automatically translating all keys in OI2 to > concrete. Ok ;) -- Teemu Arina, CTO Ionstream Oy / Dicole Komeetankuja 4 A 02210 Espoo FINLAND Tel: +358-(0)50 - 555 7636 skype: infe00 Corporate website: http://www.dicole.com Personal weblog: http://infedelic.blogspot.com "Discover, collaborate, learn." |
|
From: Chris W. <ch...@cw...> - 2005-03-08 15:43:35
|
* Teemu Arina (te...@io...) [050308 10:27]: > That's exactly what I had in mind. MO is simply compiled PO. You > write your stuff in as PO files and those get compiled in some weird > MO files. I don't know which is faster, I guess MO is more designed > towards C-based applications. You can manipulate and play around > with MO files with tools from the GNU gettext toolset. It's in the hopper: http://jira.openinteract.org/browse/OIN-143 We can add MO support later if necessary. > > FWIW, I'm also still noodling over the abstract vs concrete message > > keys and *may* wind up automatically translating all keys in OI2 to > > concrete. > > Ok ;) I should mention that OI2 does not dictate what type of keys you use in your own applications. :-) Chris -- Chris Winters (http://www.cwinters.com) Building enterprise-capable snack solutions since 1988 |
|
From: Chris W. <ch...@cw...> - 2005-03-07 14:12:20
|
Salve J Nilsen said: > ... > I've noticed the "Themes" discussion in the OI2Ideas wiki page[1], and > based on it, would like to propose some thoughts for the CSS effort > ahead. I'm sure I haven't considered everything, and hope we can get a > fruitful discussion before we start on 1.99_07... :) Thanks so much for putting this together. Probably the main reason the OI interface stuff is behind the times is because I'm behind the times. I haven't kept up with how most websites are built now (most of my $DAY_JOB web work is building or testing internal sites) so I'm unlikely to offer much help beyond backend organization and some help with making calls (like 'append_style', 'append_script', etc.) consistent. But since you guys are actively building sites with OI2 and using it in your daily work your opinions (and code) will have more weight. And you do have CVS-write access :-) I'm not sure about Teemu's suggestion about getting rid of widgets. In particular, I think the various form widgets can actually help migrate from a table-based to a style-based layout. So something like: [% INCLUDE label_form_text_row( label = 'Foo', name = 'foo', size = 30 ... ) %] can be changed behind the scenes to emit whatever is CSS-friendly instead of a table row with two cells. Maybe that's naive? That said, I do think it's easy to go overboard with the widgets. I still need to read through and digest everything you've written here. More soon. Later, Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X