Menu
▾
▴
openinteract-dev — For OI developers, includes project coordination and technical discussion.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(19) |
Nov
(22) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(35) |
Feb
(5) |
Mar
(13) |
Apr
(9) |
May
(3) |
Jun
(16) |
Jul
|
Aug
(6) |
Sep
(15) |
Oct
(5) |
Nov
(3) |
Dec
(7) |
| 2003 |
Jan
(16) |
Feb
(10) |
Mar
(19) |
Apr
(13) |
May
(5) |
Jun
(20) |
Jul
(33) |
Aug
(9) |
Sep
(1) |
Oct
(12) |
Nov
(17) |
Dec
(2) |
| 2004 |
Jan
(3) |
Feb
(9) |
Mar
(7) |
Apr
(16) |
May
(6) |
Jun
(6) |
Jul
(18) |
Aug
(8) |
Sep
(27) |
Oct
(8) |
Nov
(14) |
Dec
(29) |
| 2005 |
Jan
(1) |
Feb
(11) |
Mar
(33) |
Apr
(2) |
May
(4) |
Jun
(21) |
Jul
(41) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2006 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Chris W. <ch...@cw...> - 2005-03-23 15:15:16
|
* Teemu Arina (te...@io...) [050321 20:50]:
> I ported my applications from 1.99_04 to 1.99_06.
>
> A couple of things that I had problems with:
Thanks for posting these, they're very helpful.
> 1.
> task_name and action_name are not anymore in CTX->request. Is there
> other way to access those through the context?
Why do you need them? I thought of keeping them in the request after
implementing the ActionResolver but couldn't think of a good
reason. (And that's not saying there isn't one.)
> 2.
> My stock debian apache2 with mod_perl2 segfaults after the APR::Table fix.
> Haven't checked any further.
My mp2 experience is lacking as well.
> 3.
> If you have packages that use spops objects from one and another, you can't
> remove all of the packages with the remove_package manage task, you only end up
> breaking things. That's because oi2_manage doesn't work anymore if the package
> classes do not include properly (i.e., SPOPS class is missing). You have to manually
> edit repository.ini
I think a change I made to the 'install_package' management task would
help here -- instead of creating the context and running all setup
tasks it skips 'read packages'. (This was in response to similar
problems raised in OIN-147 and OIN-148.)
I'll give this a shot with 'remove_package' and see how it goes.
> 4.
> Why not introduce a parameter for remove_package that also deletes the package
> directory in pkg/[package_name-version]? You can't reinstall the package again
> with the same version once it has been removed, you have to remove the directory
> in pkg/ first. A parameter to do this at the same time would be nice.
Great idea -- I'll create an issue for it.
> 5.
> The user sometimes receives the following message instead of the page one
> is browsing:
> Failed to save error object: Cannot overwrite existing file
> /usr/local/oi/error/2005-03/22/071417-000.txt with error contents at OIAppender.pm line 52.
>
> So the application kinda breaks. Maybe it happens if you receive two errors at the same time?
Yeah, within the same second. DateTime apparently doesn't store
milliseconds properly (or maybe we have to use Time::HiRes somewhere?)
and that's what the '-000' on the end is supposed to be using.
I'll add an 'if exists then change name' check in the error storage
function.
> 6.
> I had to modify some of the OI2 source code. I did not commit any of these to the CVS,
> because I need to know what you think. Attached is a patch to OI2 1.99_06 with some
> changes I had to do:
>
> lib/OpenInteract2/I18N/Initializer.pm
> Well formed .PO file looks like this:
>
> msgid ""
> msgstr ""
> "Project-Id-Version: Dicole\n"
> "Last-Translator: Teemu Arina <te...@di...>\n"
> ...
> "X-Generator: Dicole\n"
>
> msgid "Add folder"
> msgstr "Add folder"
> ...
>
> It has a header with a null msgid that tells something about the content
> of the translation.
The PO parsing is done entirely in Locale::Maketext::Lexicon::Gettext,
so if there's a bug in the parsing we should probably let them know.
> OI2 Initializer.pm does some black voodoo magic with Template toolkit
> to build %Lexicon in the new class. This breaks because the msgstr of the
> header has a set of new lines. Anyway, is this TT hack really that necessary? Think
> if we move to UTF8 support later, this Template toolkit hack will break things
> (utf flags, I guess). Is there a better way (not copying the msg variables)?
Hmmm... well, I don't think it qualifies as black voodoo magic, but I
see your point. We may just want to do something like:
- create classes for all supported languages
- assign keys/values directly into created class
That way there should be no modification of the original variable and
it will maintain its utf8 (or other) metadata.
> Another problem with the TT stuff is once again the way it constructs the key
> of the hash. It doesn't take into account that the key might contain characters
> like ' or \. Also, msgstr ending in \ or strings containing {} will also break
> the TT hack.
>
> My patch is a quick hack fix to some of the above problems (removes null msgid
> key completely, fixes the TT stuff a little bit) but a more robust solution
> should be written.
I think the proposition above should take care of this.
> Also, my patch removes unnecessary dublicate key errors. If you use strings
> as keys, you most likely end up with dublicate key errors with common strings because
> all the strings are global in OI2 (fix coming soon?). This is not life threattening but
> useful to developers, so I moved the error from warn to debug (logs in end user installations
> should not fill up with errors like this).
No problem, I didn't know how often this sort of thing happened.
The global string issue is slated for fixing and I had some ideas on
how to do it:
http://jira.openinteract.org/browse/OIN-29
> lib/OpenInteract2/I18N.pm
> Changes the system so that instead of returning "Message error for '$key'"
> it returns the key itself in case no translation is found.
> This is to ensure that in incomplete translations the english version is
> displayed instead (if you use strings as keys instead of some ID values).
> There are perfectly good examples when you might want to run some strings through
> _msg and the strings will return them selves if no translation is found.
> Also moved from warn to debug the information of untranslated
> strings.
That makes sense.
> This is once again, only useful information for developers.
>
> lib/OpenInteract2/Request.pm
> OI2 always selects the language provided by the browser (user agent). Well, it was a bit
> difficult to change the language as a user, because it had no effect ;)
> I changed this chain to something more logical:
>
> Changes the order in how the language is selected:
> - prefers $lang_config->{choice_param_name} over user or session language
> - prefers user and session language over user agent provided languages
> - prefers everything else over $lang_config->{default_language}
That makes sense too. If you've got these on your system already why
don't you go ahead and commit them? If not I'll patch and commit.
Thanks!
Chris
--
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988
|
|
From: Teemu A. <te...@io...> - 2005-03-22 01:38:12
|
Hello,
I ported my applications from 1.99_04 to 1.99_06.
A couple of things that I had problems with:
1.
task_name and action_name are not anymore in CTX->request. Is there
other way to access those through the context?
2.
My stock debian apache2 with mod_perl2 segfaults after the APR::Table fix.
Haven't checked any further.
3.
If you have packages that use spops objects from one and another, you can't
remove all of the packages with the remove_package manage task, you only end up
breaking things. That's because oi2_manage doesn't work anymore if the package
classes do not include properly (i.e., SPOPS class is missing). You have to manually
edit repository.ini
4.
Why not introduce a parameter for remove_package that also deletes the package
directory in pkg/[package_name-version]? You can't reinstall the package again
with the same version once it has been removed, you have to remove the directory
in pkg/ first. A parameter to do this at the same time would be nice.
5.
The user sometimes receives the following message instead of the page one
is browsing:
Failed to save error object: Cannot overwrite existing file
/usr/local/oi/error/2005-03/22/071417-000.txt with error contents at OIAppender.pm line 52.
So the application kinda breaks. Maybe it happens if you receive two errors at the same time?
6.
I had to modify some of the OI2 source code. I did not commit any of these to the CVS,
because I need to know what you think. Attached is a patch to OI2 1.99_06 with some
changes I had to do:
lib/OpenInteract2/I18N/Initializer.pm
Well formed .PO file looks like this:
---
msgid ""
msgstr ""
"Project-Id-Version: Dicole\n"
"Last-Translator: Teemu Arina <te...@di...>\n"
"POT-Creation-Date: 2005-03-22 02:06:45+0000\n"
"PO-Revision-Date: 2005-03-22 02:06:45+0000\n"
"Language-Team: Dicole <in...@di...>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Dicole\n"
msgid "Add folder"
msgstr "Add folder"
...
---
It has a header with a null msgid that tells something about the content
of the translation.
OI2 Initializer.pm does some black voodoo magic with Template toolkit
to build %Lexicon in the new class. This breaks because the msgstr of the
header has a set of new lines. Anyway, is this TT hack really that necessary? Think
if we move to UTF8 support later, this Template toolkit hack will break things
(utf flags, I guess). Is there a better way (not copying the msg variables)?
Another problem with the TT stuff is once again the way it constructs the key
of the hash. It doesn't take into account that the key might contain characters
like ' or \. Also, msgstr ending in \ or strings containing {} will also break
the TT hack.
My patch is a quick hack fix to some of the above problems (removes null msgid
key completely, fixes the TT stuff a little bit) but a more robust solution
should be written.
Also, my patch removes unnecessary dublicate key errors. If you use strings
as keys, you most likely end up with dublicate key errors with common strings because
all the strings are global in OI2 (fix coming soon?). This is not life threattening but
useful to developers, so I moved the error from warn to debug (logs in end user installations
should not fill up with errors like this).
lib/OpenInteract2/I18N.pm
Changes the system so that instead of returning "Message error for '$key'"
it returns the key itself in case no translation is found.
This is to ensure that in incomplete translations the english version is
displayed instead (if you use strings as keys instead of some ID values).
There are perfectly good examples when you might want to run some strings through
_msg and the strings will return them selves if no translation is found.
Also moved from warn to debug the information of untranslated strings.
This is once again, only useful information for developers.
lib/OpenInteract2/Request.pm
OI2 always selects the language provided by the browser (user agent). Well, it was a bit
difficult to change the language as a user, because it had no effect ;)
I changed this chain to something more logical:
Changes the order in how the language is selected:
- prefers $lang_config->{choice_param_name} over user or session language
- prefers user and session language over user agent provided languages
- prefers everything else over $lang_config->{default_language}
Regards,
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: Chris W. <ch...@cw...> - 2005-03-21 03:57:04
|
On Mar 20, 2005, at 2:45 PM, Teemu Arina wrote: > >> use APR::Table (); > > This line did it. > Maybe it should be included in the default startup_mp2.pl? It's in there now. I haven't tried OI2 with mp2 for quite some time. IIRC I had to use CGI.pm to get the parameters working rather than mp2 implementation for Apache::Request. It would be cool to get that working and if anyone's got the time... Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Teemu A. <te...@io...> - 2005-03-20 19:45:43
|
> use APR::Table (); This line did it. Maybe it should be included in the default startup_mp2.pl? -- 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: Andreas N. <an...@kl...> - 2005-03-20 19:31:07
|
> but well it starts through startup_mp2.pl and I tried to add that one in there,
> just reports that an undefined subroutine has been called.
>
> I've included httpd_mp2_solo.conf in apache2.
>
> - Teemu
>
>
hm - maybe I do not remember right. Here is my startup_mp2.pl
--------------
#!/usr/bin/perl
use strict;
use Apache2 ();
# enable if the mod_perl 1.0 compatibility is needed
use Apache::compat ();
use ModPerl::Util (); #for CORE::GLOBAL::exit
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::ServerRec ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use APR::Table ();
use ModPerl::Registry ();
use Apache::Const -compile => ':common';
use APR::Const -compile => ':common';
use Apache2::OpenInteract2;
use CGI;
use Log::Log4perl;
use OpenInteract2::Config::Base;
use OpenInteract2::Constants qw( :log );
use OpenInteract2::Context;
CGI->compile( ':all' );
my $BASE_CONFIG_FILE = '/web/kloeterbregen/conf/base.conf';
{
Log::Log4perl::init( '/web/kloeterbregen/conf/log4perl.conf' );
my $base_config = OpenInteract2::Config::Base->new(
{ filename => $BASE_CONFIG_FILE } );
my $ctx = OpenInteract2::Context->create(
$base_config, { temp_lib_create => 'create' } );
$ctx->assign_request_type( 'apache2' );
$ctx->assign_response_type( 'apache2' );
}
1;
--------------
I did not add anything intersting to the httpd.conf - I think...
hope this helps
Andreas
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> openinteract-dev mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-dev
--
Andreas Nolte <an...@kl...>
|
|
From: Andreas N. <an...@kl...> - 2005-03-20 19:25:58
|
> I'm running Debian Sarge. OI2 works just fine under apache 1.x, directly from > the official debian packages. I also wanted to test OI2 under Apache2 but > it didn't work. I get the following error in error_log_mp2: > > Can't locate object method "FETCH" via package "APR::Table" at > /usr/share/perl5/Class/Accessor/Fast.pm line 39. > > I have installed libapache2-mod-perl2 (provides APR::Table) and libapache2-request-perl. > > Has anyone successfully installed OI2 with Apache2 under Debian Sarge? > Salve? > Hi Teemu, I did not test with debian, but RH 9 at that time and remember the error. What happens here is, that modperl 1.x classes are used. Just drop in Apache::compat() somewhere ( like startup.pl ) and it should work. cheers Andreas -- Andreas Nolte <an...@kl...> |
|
From: Teemu A. <te...@io...> - 2005-03-20 19:23:39
|
> I did not test with debian, but RH 9 at that time and remember the > error. What happens here is, that modperl 1.x classes are used. Just > drop in Apache::compat() somewhere ( like startup.pl ) and it should > work. Thanks, but well it starts through startup_mp2.pl and I tried to add that one in there, just reports that an undefined subroutine has been called. I've included httpd_mp2_solo.conf in apache2. - Teemu |
|
From: Teemu A. <te...@io...> - 2005-03-20 17:14:40
|
Hello, I tested latest 1.99_06 and I'm working on making my software compliant with it. I'm running Debian Sarge. OI2 works just fine under apache 1.x, directly from the official debian packages. I also wanted to test OI2 under Apache2 but it didn't work. I get the following error in error_log_mp2: Can't locate object method "FETCH" via package "APR::Table" at /usr/share/perl5/Class/Accessor/Fast.pm line 39. I have installed libapache2-mod-perl2 (provides APR::Table) and libapache2-request-perl. Has anyone successfully installed OI2 with Apache2 under Debian Sarge? Salve? -- 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: Chris W. <ch...@cw...> - 2005-03-14 03:21:57
|
Not quite as much going on this week (real-life intrudes), but still some good progress: Package configuration moved -------------------- (Issue: OIN-117) Usable package configuration files (for actions and SPOPS objects) are now under the website's 'conf/' directory and NOT in the individual package directorie -- the package 'news' will have its files as: $WEBSITE_DIR/conf/news/action.ini $WEBSITE_DIR/conf/news/spops_news.ini ... This working copy will never get overwritten with package upgrades: if a package modifies its own configuration the updated file will be rewritten to a subdirectory 'updates/' and the differences can be merged manually. This also means we'll be getting rid of the 'GlobalOverride' configuration modifier. Less code! More localization source formats -------------------- (Issue: OIN-143) You can now use PO and MO files to provide localization messages. The methods for referencing the messages doesn't change and don't need to know where they came from. Additionally, a package can use both PO/MO files and the custom OI2 message format. Smaller items worth noting -------------------- OIN-72: Finish up the work necessary to make OI2 packages CPAN-distributable and modify all the core and extra packages to support it. OIN-46, OIN-53, OIN-92: Documentation updates to API guidelines, apache administration, and tutorial on advanced features. OIN-150: Salve fixed references from 'action_errors' to 'action_messages' in templates. Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Chris W. <ch...@cw...> - 2005-03-11 05:35:59
|
Just so you know: JIRA notifications are currently not working. I think it's a DNS issue and have asked the folks who maintain the openinteract.org domain to check on something. But that may be a red herring... I hate mail servers. Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
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: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: 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: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...@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: 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. |
|
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-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: Chris W. <ch...@cw...> - 2005-03-04 15:58:37
|
The goal of getting 1.99_06 out the door by mid-March still looks good. A number of JIRA issues were closed this week and we're now down to 13 open for 1.99_06. Lots of stuff this week: REST parameters now supported -------------------- (Issue: OIN-135) OI2 can now parse additional URL parameters into action parameters. So you can use something like: http://www.foo.com/news/display/39 instead of: http://www.foo.com/news/display/?news_id=39 or: http://www.foo.com/news/archive/2005/03 instead of: http://www.foo.com/news/archive/?year=2005&month=03 There's a discussion of this on my website at the not-yet-RESTed: http://www.cwinters.com/news/display/?news_id=3342 One format to bind them all: INI -------------------- (Issues: OIN-136 and OIN-137) One set of changes eliminated all other configuration types except INI. The last two holdouts were the package configuration (package.conf) and the bootstrapping 'base' server configuration (base.conf). Both are now INI format which should be good for consistency. If you upgrade vs installing a new server you'll need to modify your existing files. The 'base.conf' has been renamed to 'bootstrap.ini' and changing it over should take you about 30 seconds manually. And there's a script in the 'script/' distribution directory to translate a package.conf to package.ini. Package updates: get rid of doc/foo.pod -------------------- (Issue: OIN-72) As part of making all packages buildable into CPAN-distributable packages the documentation previously in a separate POD file in the package's 'doc/' directory has been moved to the new 'OI2::App::MyPackage' class. This isn't mandated for existing packages, but the system_doc package has been modified to only display docs from Perl modules. Package updates: comments -------------------- (Issues: OIN-112, OIN-119 and OIN-128) A few useful feature updates for the 'comments' package. You can now demarcate preformatted text, useful for websites (like mine) where people may post samples. The logic for subscribing/unsubscribing from a thread is also improved, and if you revisit a thread to which you're subscribed you'll have an indication of it. As an admin you can now also turn off comments for an individual object or for a whole class of objects. Smaller items -------------------- OIN-92: Lots of docs added to the advanced tutorial (OI2::Manual::TutorialAdvanced). OIN-134: When running 'install_sql_structure' management task to install SQL tables you can now restrict it to certain files. (Makes for easier upgrades when you add tables between package versions.) OIN-91: When users create an account we set a 'removal_date' on their record. The date is removed at first login. But we didn't have anything to cleanup unused accounts. New management task (clean_users) does this. OIN-140: Be able to assign security to action class through management task. Chris -- Chris Winters (http://www.cwinters.com) Building enterprise-capable snack solutions since 1988 |
|
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: Chris W. <ch...@cw...> - 2005-03-03 18:13:16
|
Salve J Nilsen said: > ... > I was wondering... What was the purpose of testing package versions? To > me it seems rather annoying to both have to update MANIFEST and > t/utils.pl every time a package is changed. > > I'd think it would be more sensible to extract package versions from the > MANIFEST file, or drop the tests entirely... :-\ Yep, you're right, I can't think of a good reason either. I'll get rid of the version checks this evening. Thanks for pointing out the obvious -- a fresh set of eyes can do wonders :-) Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Chris W. <ch...@cw...> - 2005-02-25 18:23:23
|
Perrin Harkins said: > On Thu, 2005-02-24 at 19:30 -0500, Chris Winters wrote: >> - Get infrastructure to support Class::DBI and simple >> sample app working (need to learn more) > > Feel free to ask for help when you get to this part. You read my mind. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Perrin H. <pe...@el...> - 2005-02-25 18:10:32
|
On Thu, 2005-02-24 at 19:30 -0500, Chris Winters wrote: > - Get infrastructure to support Class::DBI and simple > sample app working (need to learn more) Feel free to ask for help when you get to this part. - Perrin |
|
From: Chris W. <ch...@cw...> - 2005-02-25 00:21:59
|
OI2 status report (2005-02-24)
------------------------------
For the first status report an overview is probably in order. Here's
what I see right now as upcoming releases, subject to change as
typical:
2.0 beta 6 (1.99_06)
Target: mid March
- Fix the remaining issues in JIRA
- Cleanup log messages according to recent emails as much as possible
- While doing that localize error messages throughout system.
2.0 beta 7 (1.99_07)
Target: late April
- Fix outstanding issues.
- Integrate existing 'delicious_tags' package to core and replace
some application functionality with it (like news sections).
- Finish log message cleanup.
- Finish localizing error messages.
- Get someone who knows design to help out with website/CSS
- Get infrastructure to support Class::DBI and simple
sample app working (need to learn more)
2.0
Target: late May, early June
- Hopefully small fixes
- More localization messages?
Recent work lately has been:
- 80% done: Being able to package and install OI2 application
packages using CPAN tools. So you'll be able to do something like:
# install to local perl
> perl -MCPAN -e 'install OpenInteract2::App::PhotoManager'
# install to local website method 1
perl -MOpenInteract2::App::PhotoManager -e 'install()'
# install to local website method 2
> oi2_manage install_package --class=OpenInteract2::App::PhotoManager
- 95% done: Create little objects and an organizer to figure out which
OI2::Action object to run based on the URL (or whatever). I
referenced this in a recent journal post:
http://www.cwinters.com/news/display/?news_id=3333
This is in OI2::ActionResolver and children and kicked off in
OI2::Controller.
- 95% done: Create little objects and an organizer to run setup
routines; this tore apart the monolithic OI2::Setup class into a
number of little classes that get organized at runtime by
Algorithm::Dependency. This change makes it possible to easily add
your own routines that get run at server startup -- all you need to
do is be in the OI2::Setup namespace and tell us a little about
yourself (name and dependencies).
- 100% done: Added FastCGI interface. I haven't used FastCGI before
but it works and seems simple enough...
- 80% done: Rewriting the 'base_error' package and its support to
not store errors in the database but use the filesystem instead.
I can go into detail on these, but this is already a long email...
Later,
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: Chris W. <ch...@cw...> - 2005-02-24 15:05:06
|
Salve J Nilsen said: >> - If we set the threshold to 'FATAL' we don't store anything -- nothing >> is logged with a 'FATAL' level. > > This doesn't necessary have to be a bad thing... Are there any > situations that should be fatal to OI2? e.g. missing critical > dependencies, inability to contact critical databases, badly broken > (truncated?) primary config files, inability to access local files at > all (broken filesystem.) These were all I could think of, although at least the dependencies should get caught at server startup vs runtime. > At this level, I hope never to get any output to the log files. :) > >> - If we set the threshold to 'ERROR' we store a ton of messages, too >> many to be useful. > > Do _all_ these messages deserve an "ERROR" status, or are some of them > only informational? The ones that actually _are_ errors, should of > course be fixed. :) That's the problem -- while all of them are errors, some aren't ones you'd actually care about. For instance, when you lookup an action with an incorrect name OI2 will log an error. Yes, it is an error, but is it one we need to log? Probably not, since the caller is in a better position to evaluate whether it's actually an error. There are lots of these, unfortunately. It'll just take some time to go through them but it's worth the time. > > FATAL > > Fatalities (death). Situations where the system/application cannot > continue safely and must abort. Manual intervention is necessary to get > things running again. (Hopefully, this is something you'll never need to > see. :) Right -- database crash, cannot load vital components (e.g., packages), etc. > > ERROR > > Actual errors that need to be looked into. The application should be > able to continue running despite having these errors, but should > probably tell the user why the expected data can't be delivered. So would this include not being able to store data in the database because of bad data? Or failing to execute a query because of a typo in the fieldname? >> WARN > > For situations that at some point later may lead to errors. E.g. missing > directories, use of default values in system-dependent configuration > (e.g. when using a default IP address of 127.0.0.1, when it should have > been defined explicitly in some config file.) I'd probably add security violations to this. > > INFO > > High/Coarse-level status messages. I try to use this to tell when > important subsystems are used, and what data they recieve/pass along. Good guidelines. Not a lot of data is in these but more like a guide as to what path the application is taking. > > DEBUG > > Detailed status messages, debugging, and all the rest. Personally I'd > like several debug levels, but existing logging frameworks like > syslog(1) and log4* seem to disagree with me. :) Yeah, everything else goes here :-) Thanks! Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
1 message has been excluded from this view by a project administrator.
