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: Pronichev A. <dy...@ag...> - 2005-07-05 13:31:19
|
Hello everybody. Does anybody know anything about subject? How can I use transactions in SPOPS (may be somebody already wrote such module)? I would like to write something like this in my SPOPS object package: package My::SPOPS::Foo; .... sub pre_save_action { my $c = shift; my $tr = SPOPS::Transaction->new( $c->global_datasource_handle ); my $object2 = My::SPOPS::Bar->new(...); $tr->add_dbh( $object2->global_datasource_handle ); ... $obj->save or $tr->rollback('error message'); ... 1; } sub post_save_action { my $c = shift; if $c->transaction { my $tr = $c->transaction; # This will commit ALL dbh, added by add_dbh $tr->commit or $tr->rollback('error message'); } 1; } package main; .... my $foo = My::SPOPS::Foo->new(); ... $foo->save or My::Exception->throw(...); Thanks in advice. -- WBR dyker Agava Software |
From: Salve J N. <sal...@me...> - 2005-07-05 12:01:10
|
Antti M Vähäkotamäki wrote: > Well to make this clear from the beginning - I'm not in any way against > you building new templates. They will be needed for sure. I'm just > trying to look at the bigger picture. > > Salve J Nilsen wrote: > >> Urgh... I'm sorry about that. OI2 is definitly a application framwork >> (where of "CMS" is only a minor part.) I didn't mean to cause this >> confusion. :-\ > > Well what I was thinking was more in the lines of OI2 not being even > partly a CMS. I'm sure you can mold OI2 into whatever you want it to be... :-) > Sure I would heartly welcome a package which would implement all kinds > of CMS functionality on top of OI2, and an another package which would > provide a bucketfull of general TT2 templates which are easily themable > by pure CSS, but I'm not sure if either of these should be included in > the base packages IF they are to provide a general base for applications. I think having a functional website with CMS, news and security features as part of the "base" is not only good, but the Sensible Thing to Do. OI2's CMS features (e.g. page management and publishing, user/group management, interface consistency features, templates, logging framework, etc.) may be a bit lacking (in consistency, standards compliance, visual beauty and so on.) but having them available from a basic install quite important. Who do you think would be impressed by a application framwork one can't test and experiment with? > So probably the bigger question here is the meaning of base packages - > what are they for? They're there so you can get a notion of what's possible to do OI2, and when you've seen _that_, the _real_ big questions show up: How can I use OI2? How can I improve OI2? What should be improved? How easy is it to improve OI2? How can I make it easier to improve OI2? What should be improved so OI2 becomes easier to improve? > Also currently the building block TT2 templates for OI2 website aren't > even in a base package but they are directly in the website's template > directory. This makes them impossible to be substituted or modified > through the management system with packages. I'm not sure if the current > theme implementation can be used to override these (we are using it only > to load a single theme which causes a constant 50ms addition to each > request ;-) ), but if we are getting rid of the current theming for a > CSS only theming, we can't do this anymore and the whole thing should be > rethought. I'm sure you can find or formulate some bug reports that describe what your problems are. <http://jira.openinteract.org/> ;-) (And yes, the theme implementation sucks :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
From: <an...@io...> - 2005-07-04 16:37:29
|
Chris Winters wrote: > Hey, if FastCGI works better with CGI::Fast I'm all for switching. Are > there any other side effects? And is CGI::Fast the more commonly used > interface? (I've never used FastCGI in production, so it's all a shot > in the dark for me...) I haven't used it in production either.. I'm just running my development box under FastCGI now since I'm experiencing somekind of a memory consuming loop when I stop my apache when it has served an OI2 request under mod_perl (Which then causes wild swapping of _everything_). CGI::Fast seems to be older than FCGI and not updated in a while, but that doesn't necessarily make it outdated. Maybe the motivation behind FCGI has been jut to provide a version of FastCGI gateway which is independent of the CGI.pm module, which some people concider bloated. So pretty blind shots for me also, but for my use it seems that CGI::Fast works better. I haven't seen any side effects yet except that is fixes the post parameter problem. .. By the way I think CGI request doesn't mix url parameters with post parameters like Apache request does. They can be acquired from CGI object with url_param() just like post params are acquired using param(). It might be nice to add some kind of a separation for post and url params in OI2 also (I think this is already in JIRA by Teemu?) and make the behaviour consistent across different Requests. Maybe so that all the params are stuffed to $request->param but they are also ackquirable intependently with $request->url_param and $request->post_param ? - Antti |
From: Chris W. <ch...@cw...> - 2005-07-04 14:47:33
|
On Jul 2, 2005, at 5:49 PM, Antti M V=E4h=E4kotam=E4ki wrote: > Thought about this some more. I think it is a good idea to reserve =20 > an accessor (or a parameter) in the action for the array of all =20 > additional parts since it defines the action much like action's =20 > name or it's task. You never know when it is needed ;) That's probably a good idea. I moved the code to assign these from =20 the request into a separate subroutine as well, so you can do: # assign the additional parameters from the Request object $action->url_additional_param_from_request; my @values =3D url_additional_param; BTW, is there a better name for these things? Calling everything =20 'url_additional' is very klunky and not terribly descriptive. > Also it would be nice to add the rest of the additional parts, =20 > which were not mapped to a param, to a separate param. > > So if your url would be: > /filearea/download/users/madonna/music/garbage.mp3 > > and your action.ini would have: > [filearea url_additional] > download =3D area_type > download =3D area_id > > The you would end with an action such that: > $action->additional -> [ 'users', 'madonna', 'music', 'garbage.mp3' ] > $action->param('area_type') -> 'users' > $action->param('area_id') -> 'madonna' > $action->param('other_additional') -> [ 'music', 'garbage.mp3' ] > > What do you think? It's not a bad idea. (That Action class just keeps growing... :-) > Also in Dicole we have a $action->derive_url -function which tries =20 > to take the current action's url and modify it a bit: > $action->derive_url( task =3D> 'view') =3D> /filearea/view/users/=20 > madonna/music/garbage.mp3 > > You might want concider something similiar for OI2 - it has been =20 > quite handy for our use since we also usually have an additional id =20= > in the url specifying target user or group and it hardly ever =20 > changes. We haven't yet modified it to use url_additional settings =20 > so that it would be possible to override also those in a similiar =20 > fashion, but I think it will be done at some point like this: > $action->derive_url( area_id =3D> 'bjork', other_additional =3D> =20 > [ 'robots.txt'] ) -> /filearea/download/users/bjork/robots.txt I think a lot of the functionality in OpenInteract2::URL does this. =20 For instance, to replicate the above you'd do: $action->create_url({ TASK =3D> 'view', URL_PARAMS =3D> [ 'users', =20= 'madonna', ... ] ); Creating a shortcut to fill the URL_PARAMS with default values, or to =20= be smarter to associate some additional parameters with named values =20 (like your 'area_id' above) seems application-specific, and may be =20 more appropriate a base Action class in your app. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2005-07-04 14:16:02
|
On Jul 3, 2005, at 8:03 PM, Antti M V=E4h=E4kotam=E4ki wrote: > Is there a reason why OI uses FCGI instead of CGI::Fast? I don't think there's a reason; I just wanted to get something =20 working quickly and figured if someone knew better they'd speak up. I guess I was right :-) > I started experimenting with FastCGI again and experienced some odd =20= > things like CGI not reseting its POST parameters. These problems =20 > seem to have disappeared when I switched to CGI::Fast. > > My fastcgi loop is > while ( my $c =3D CGI::Fast->new() ) { > and I create request: > my $request =3D OpenInteract2::Request->new( { cgi =3D> $c } ); So the CGI::Fast object is a subclass of CGI.pm? Cool. > Interestingly OpenInteract2::Request::CGI already contains the code =20= > for this to work as it should.. So... What's going on? =3D) Hey, if FastCGI works better with CGI::Fast I'm all for switching. =20 Are there any other side effects? And is CGI::Fast the more commonly =20 used interface? (I've never used FastCGI in production, so it's all a =20= shot in the dark for me...) Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: <an...@io...> - 2005-07-04 00:03:45
|
Is there a reason why OI uses FCGI instead of CGI::Fast? I started experimenting with FastCGI again and experienced some odd things like CGI not reseting its POST parameters. These problems seem to have disappeared when I switched to CGI::Fast. My fastcgi loop is while ( my $c = CGI::Fast->new() ) { and I create request: my $request = OpenInteract2::Request->new( { cgi => $c } ); Interestingly OpenInteract2::Request::CGI already contains the code for this to work as it should.. So... What's going on? =) - Antti |
From: <an...@io...> - 2005-07-02 21:49:26
|
Antti M Vähäkotamäki wrote: > By the way, assigning url_additional automatically according to > configuration is a brilliant idea in many ways :) I just started to > think of it more and concluded that if the task could be determined > before execute then we could assign url_additional before execute, we > possibly wouldn't need the additional url parameters in action anymore, > thus separating us from the request.. nice :) Thought about this some more. I think it is a good idea to reserve an accessor (or a parameter) in the action for the array of all additional parts since it defines the action much like action's name or it's task. You never know when it is needed ;) Also it would be nice to add the rest of the additional parts, which were not mapped to a param, to a separate param. So if your url would be: /filearea/download/users/madonna/music/garbage.mp3 and your action.ini would have: [filearea url_additional] download = area_type download = area_id The you would end with an action such that: $action->additional -> [ 'users', 'madonna', 'music', 'garbage.mp3' ] $action->param('area_type') -> 'users' $action->param('area_id') -> 'madonna' $action->param('other_additional') -> [ 'music', 'garbage.mp3' ] What do you think? Also in Dicole we have a $action->derive_url -function which tries to take the current action's url and modify it a bit: $action->derive_url( task => 'view') => /filearea/view/users/madonna/music/garbage.mp3 You might want concider something similiar for OI2 - it has been quite handy for our use since we also usually have an additional id in the url specifying target user or group and it hardly ever changes. We haven't yet modified it to use url_additional settings so that it would be possible to override also those in a similiar fashion, but I think it will be done at some point like this: $action->derive_url( area_id => 'bjork', other_additional => [ 'robots.txt'] ) -> /filearea/download/users/bjork/robots.txt - Antti |
From: Jeff H. <je...@je...> - 2005-07-02 04:14:00
|
Teemu, ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > From: Teemu Arina > > A note about info/help boxes next to forms, I've seen > in plone they have info boxes so that when you have > focus in a certain element, the help for the element > appears right next to the element as a layer. This way > the layout remains compact and clean. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I've never really liked the way Plone does it. Perhaps something similar, but better. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > You might also want to have: > > (year, month, day) (hour, minute, second) > (year, month, day) (hour, minute) > (hour, minute) > (hour, minute, second) > > Then the ordering of year, month, day should be based on > users localization settings (OI2 developers problem). > Hours might also have [AM]/[PM] option dropdown for US. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Agreed. I can add some simple styling to accommodate any of the above varieties. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > >> +--------+ +--------+ > >> |foo | |bah | > >> |bar | [>>] |quux | > >> |baz | [->] | | > >> |bom | [<-] | | > >> | | [<<] | | > >> | | | | > >> +--------+ +--------+ > > With some javascript and replacing the form elements > with simple divs this is possible to implement as a > drag & drop version as well, eliminating the need for > arrows. Non-js could be implemented with just one > ctrl-selectable select list element. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Drag and drop does not remove the need for arrows. Each is necessary to address the assortment of user interaction styles. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > I'll need more information on what you mean by > > "View"-versions. > > I guess Salve means read-only versions. For date field, > we will have e.g. "11th June 2005". Read-only in forms > is probably implemented with the readonly property of > form elements or with hidden fields together with a div > or something to display the contents of the hidden > field(s). ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Ah, so I'll need some very basic styling to address both read-only fields and other markup used to display read-only data. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > I'm not quite sure how this applies to forms, which is > > what I'd like to limit my involvement to. > > Well if it's possible to separate a long form into > multiple segments, each segment accessible through a > tab without reloading the page. Non-javascript version > could just display the complete form on a single page. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Ah, now I understand. My extensive experience building complicated forms has taught me that you can't really effectively do a multi-page form all client-side without enormous amounts of JavaScript. It seems the more data the form must collect the more "conditional" elements found later in the form become. My personal opinion is that if you have a need to break something into multiple pages, it's best to keep that functionality strictly server-side. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > Yeah, it'd definitely have to be lightweight. The > > dynarch version is nice, but definitely not fast. > > So far as I know this is the best one there is out there > in the Open Source domain which works accross multiple > different browser versions. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Personally, if something can't be done about the speed, I'd rather just not use it at all. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > >> - default-layout.css > >> - default-menus.css > >> - default-content.css > >> - default-forms.css > > We had layout.css and markup.css to separate positioning > (margins, paddings etc) from display (colors, borders > etc). ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< In my own development I usually break my styles down like so: Linked: tags.css layout.css form.css Imported: tags.import.css layout.import.css form.import.css Optionally, I'll add a home.css after layout.css in the linked section and home.import.css in the imported section after layout.import.css for the homepage if the styling that page demands is sufficiently different. [>] Jeff Howden je...@je... http://jeffhowden.com/ |
From: Teemu A. <te...@di...> - 2005-07-01 22:59:13
|
A note about info/help boxes next to forms, I've seen in plone they have info boxes so that when you have focus in a certain element, the help for the element appears right next to the element as a layer. This way the layout remains compact and clean. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> * A "date selection" widget, consisting of three >> <select> dropdown lists (year, month, day). I'd >> like to replace this one with a proper calendar >> widget, sometime. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< You might also want to have: (year, month, day) (hour, minute, second) (year, month, day) (hour, minute) (hour, minute) (hour, minute, second) Then the ordering of year, month, day should be based on users localization settings (OI2 developers problem). Hours might also have [AM]/[PM] option dropdown for US. >> +--------+ +--------+ >> |foo | |bah | >> |bar | [>>] |quux | >> |baz | [->] | | >> |bom | [<-] | | >> | | [<<] | | >> | | | | >> +--------+ +--------+ With some javascript and replacing the form elements with simple divs this is possible to implement as a drag & drop version as well, eliminating the need for arrows. Non-js could be implemented with just one ctrl-selectable select list element. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> * If you still have too little to do, then >> "View"-versions of the widgets would be nice. >> Especially for list-type, tabular and hierarchical >> data. >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > I'll need more information on what you mean by "View"-versions. I guess Salve means read-only versions. For date field, we will have e.g. "11th June 2005". Read-only in forms is probably implemented with the readonly property of form elements or with hidden fields together with a div or something to display the contents of the hidden field(s). > I'm not quite sure how this applies to forms, which is what I'd like to > limit my involvement to. Well if it's possible to separate a long form into multiple segments, each segment accessible through a tab without reloading the page. Non-javascript version could just display the complete form on a single page. > Yeah, it'd definitely have to be lightweight. The dynarch version is nice, > but definitely not fast. So far as I know this is the best one there is out there in the Open Source domain which works accross multiple different browser versions. >> - default-layout.css >> - default-menus.css >> - default-content.css >> - default-forms.css We had layout.css and markup.css to separate positioning (margins, paddings etc) from display (colors, borders etc). >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> * It would be nice if all CSS measurements were in >> em's and not px'en, so that page scaling works >> better (increasing the text size in your browser). >><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > I'm personally not a big fan of ems as they do funny things cross-browser. With fonts I guess percents work best cross-browser. Plone.org has very good CSS implementations, see how they use ems and percents. Regards, Teemu Arina Dicole http://www.dicole.org FLOSS in education blog: http://flosse.dicole.org "Discover, collaborate, learn." |
From: Jeff H. <je...@je...> - 2005-07-01 16:55:29
|
Salve, ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > From: Salve J Nilsen [mailto:sj...@pv...] > > To give you some background, you can have a look at our > initial thoughts at > <http://sourceforge.net/mailarchive/message.php?msg_id=11059887>. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I have not had a chance to read the above yet, but will do so when I get a Net connection next. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > Feel free to join the list and introduce yourself! We'd > be more than happy to discuss details with you. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm already subbed to way more than I can handle, but I'll give it a go for a short while. If the traffic is tolerable, I'll stay. ;) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > Basically, we need the following "widgets" (which is > generally the same as "forms", except that one widget > can consist of several related form elements), in > addition to the ones you've created already: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I expected some controls that might be called widgets that were made up of more than a single control. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * A "date selection" widget, consisting of three > <select> dropdown lists (year, month, day). I'd > like to replace this one with a proper calendar > widget, sometime. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Already done. It even corrects the number of days available for the month selected and whether or not it's leap year. http://jeffhowden.com/code/javascript/calendar/ I can integrate it easily into the example. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * If it's feasible (and you have the time), a > "multiple select" widget like this (use a > fixed-width font to see the ascii-drawing): > > +--------+ +--------+ > |foo | |bah | > |bar | [>>] |quux | > |baz | [->] | | > |bom | [<-] | | > | | [<<] | | > | | | | > +--------+ +--------+ > > Where the [>>] and [<<] buttons transfer all > <option>s from one <select> box to the other, > and [<-] and [->] transfer just one at a > time. You don't have to bother with the > JavaScript details (we already have that > covered), just make it look OK. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< My custom CMS uses something just like that. We also have another one like the following that allows controlling the order of the items on the right: +--------+ +--------+ |foo | |bah | |bar | [>>] |quux | [<<] |baz | [->] | | [<] |bom | [<-] | | [>] | | [<<] | | [>>] | | | | +--------+ +--------+ You've got to imagine the angle brackets on the right side are turned 90 degrees clock-wise. I have written scripts to make it so that more than one item can be selected and the ranking buttons still work correctly. I also have enabled additional events like double-clicking to move items out of one list and into the other. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * We need a widget that can edit hirearchical data in > an easy and sensible way. I have a couple of ideas > if you're interested in looking at this, but if > you're not, then that's fine too. :) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I currently use a multi-select with padding to represent the hierarchy. The control also has indent, outdent, rank up, and rank down buttons. It even goes so far as to select all children when a parent is selected. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * If you still have too little to do, then > "View"-versions of the widgets would be nice. > Especially for list-type, tabular and hierarchical > data. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'll need more information on what you mean by "View"-versions. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * Some minimal/clean HTML-only tabs, similar to the > feature described at > <http://www.w3.org/Style/Examples/007/target.html>, > that work nicely with the content area. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm not quite sure how this applies to forms, which is what I'd like to limit my involvement to. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * An extra-wide textarea, which could be used with > WYSIWYG HTML editors like FCKeditor. > <http://www.fckeditor.net/> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< You need something wider than the current "wide" textarea? ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * A proper calendar widget, e.g. a lightweight version > of > <http://www.dynarch.com/projects/calendar/> ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Yeah, it'd definitely have to be lightweight. The dynarch version is nice, but definitely not fast. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > CSS/looks/layout requirements: > > * A clean, minimal design. There's no point in making > lots of fancy features and graphics, just enough to > make it neat and usable. It's more importnant that > the people who'd like to use OI2 can change it > without much effort. > > * All CSS color information should be contained in a > seperate CSS file - to make it easy for other > webdesigners to create color schemes. CSS related to > the forms must be placed in a seperate file too, for > easy access/cascading. Likewise for page structure > and menus. An example set of CSS files, may be: > > - default-layout.css > - default-menus.css > - default-content.css > - default-forms.css > > These should be nicely overridable by appending > new CSS files to the CSS @import list. (And thus > we achieve "cascading" :) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Easily. Just a few declarations and the entire color scheme can be easily changed without affecting the layout at all. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * The way you structured your forms is a great start. > The only thing that could be improved, is to > somehow make them variable-width, so they look > good in (or even fit well into) the content column: > > |<--------------------- content column ---------------------->| > > |<- label ->| |<- form widgets or comments ->| |<- info-box ->| > | | | variable-width, with | | | > | | | optional help link | | | > > We also need space on the right side of each form > element for an optional [help] link, similar to this: > > [<a class="help" href="/some/help/url" > title="A short help text or explanation">?</a>] ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I hadn't considered an optional, additional help link. I guess I imagined that the info box along with explanatory text below any field would be sufficient. I'll see what I can come up with. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * It would be nice if all CSS measurements were in > em's and not px'en, so that page scaling works > better (increasing the text size in your browser). ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm personally not a big fan of ems as they do funny things cross-browser. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * The page should look good when serialised (e.g. > when turning off CSS), with the left menu columns > showing first, then the content, and then the > optional menus last. The forms and content must > make sense when you look at it serialised, and > read out the text aloud. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Yeah, this is a nobrainer, imo. It can be difficult to do without adding non-semantic markup like <br />. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * Likewise, everything must work flawlessly without > javascript. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Amen to that. However, have fun with some of the more complex widgets without JavaScript. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > I hope these "requirements" aren't too difficult. > > Are you up for it, Jeff? :-) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Time is the only issue. [>] Jeff Howden je...@je... http://jeffhowden.com/ |
From: Jeff H. <je...@je...> - 2005-07-01 09:23:10
|
Salve, ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > From: Salve J Nilsen [mailto:sj...@pv...] > > To give you some background, you can have a look at our > initial thoughts at > <http://sourceforge.net/mailarchive/message.php?msg_id=11059887>. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I have not had a chance to read the above yet, but will do so when I get a Net connection next. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > Feel free to join the list and introduce yourself! We'd > be more than happy to discuss details with you. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'm already subbed to way more than I can handle, but I'll give it a go for a short while. If the traffic is tolerable, I'll stay. ;) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > Basically, we need the following "widgets" (which is > generally the same as "forms", except that one widget > can consist of several related form elements), in > addition to the ones you've created already: ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I expected some controls that might be called widgets that were made up of more than a single control. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * A "date selection" widget, consisting of three > <select> dropdown lists (year, month, day). I'd > like to replace this one with a proper calendar > widget, sometime. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Already done. It even corrects the number of days available for the month selected and whether or not it's leap year. http://jeffhowden.com/code/javascript/calendar/ I can integrate it easily into the example. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * If it's feasible (and you have the time), a > "multiple select" widget like this (use a > fixed-width font to see the ascii-drawing): > > +--------+ +--------+ > |foo | |bah | > |bar | [>>] |quux | > |baz | [->] | | > |bom | [<-] | | > | | [<<] | | > | | | | > +--------+ +--------+ > > Where the [>>] and [<<] buttons transfer all > <option>s from one <select> box to the other, > and [<-] and [->] transfer just one at a > time. You don't have to bother with the > JavaScript details (we already have that > covered), just make it look OK. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< My custom CMS uses something just like that. We also have another one like the following that allows controlling the order of the items on the right: +--------+ +--------+ |foo | |bah | |bar | [>>] |quux | [<<] |baz | [->] | | [<] |bom | [<-] | | [>] | | [<<] | | [>>] | | | | +--------+ +--------+ You've got to imagine the angle brackets on the right side are turned 90 degrees clock-wise. I have written scripts to make it so that more than one item can be selected and the ranking buttons still work correctly. I also have enabled additional events like double-clicking to move items out of one list and into the other. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * We need a widget that can edit hirearchical data in > an easy and sensible way. I have a couple of ideas > if you're interested in looking at this, but if > you're not, then that's fine too. :) ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I currently use a multi-select with padding to represent the hierarchy. The control also has indent, outdent, rank up, and rank down buttons. It even goes so far as to select all children when a parent is selected. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * If you still have too little to do, then > "View"-versions of the widgets would be nice. > Especially for list-type, tabular and hierarchical > data. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< I'll need more information on what you mean by "View"-versions. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * Some minimal/clean HTML-only tabs, similar to the > feature described at > <http://www.w3.org/Style/Examples/007/target.html>, > that work nicely with the content area. ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > * An extra-wide textarea, which could be used with > WYSIWYG HTML editors like FCKeditor. > <http://www.fckeditor.net/> > > * A proper calendar widget, e.g. a lightweight version of > <http://www.dynarch.com/projects/calendar/> > > > CSS/looks/layout requirements: > > * A clean, minimal design. There's no point in making lots of fancy > features and graphics, just enough to make it neat and > usable. It's > more importnant that the people who'd like to use OI2 can > change it > without much effort. > > * All CSS color information should be contained in a > seperate CSS file - > to make it easy for other webdesigners to create color > schemes. CSS > related to the forms must be placed in a seperate file > too, for easy > access/cascading. Likewise for page structure and menus. > An example > set of CSS files, may be: > > - default-layout.css > - default-menus.css > - default-content.css > - default-forms.css > > These should be nicely overridable by appending new CSS > files to the > CSS @import list. (And thus we achieve "cascading" :) > > > * Looks: The traditional page layout for OI1 and OI2 has been two > columns (as far as I know): > > |<------------------ browser page width ---------------->| > > |<---------- variable-width -------->| |<- fixed-width ->| > | content | | menus | > > I'd like to change this to a two/three-column layout: > > |<- fixed ->| |<----- variable-width ----->| |<- fixed ->| > | menus | | content | | OPTIONAL | > | | | | | menus | > > Without the optional menus, the columns should look like this: > > |<- fixed ->| |<------------- variable-width ----------->| > > The optional menus column is for application "toolboxes" > that could > contain almost anyting (they may be subject to access > restrictions, > that's why they're "optional"). The left menu column is for > hirearchical lists and/or menus. > > * The way you structured your forms is a great start. The > only thing that > could be improved, is to somehow make them > variable-width, so they look > good in (or even fit well into) the content column: > > |<--------------------- content column ---------------------->| > > |<- label ->| |<- form widgets or comments ->| |<- info-box ->| > | | | variable-width, with | | | > | | | optional help link | | | > > We also need space on the right side of each form element for an > optional [help] link, similar to this: > > [<a class="help" href="/some/help/url" > title="A short help text or explanation">?</a>] > > * It would be nice if all CSS measurements were in em's and > not px'en, so > that page scaling works better (increasing the text size in your > browser). > > * The page should look good when serialised (e.g. when > turning off CSS), > with the left menu columns showing first, then the > content, and then > the optional menus last. The forms and content must make > sense when you > look at it serialised, and read out the text aloud. > > * Likewise, everything must work flawlessly without javascript. > > > I hope these "requirements" aren't too difficult. > > Are you up for it, Jeff? :-) > > > - Salve > > -- > #!/usr/bin/perl > sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# > Salve Joshua Nilsen > getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# > <sj...@fo...> > '2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}"; > __END__ is near! :) > |
From: <an...@io...> - 2005-06-30 22:15:08
|
Salve referred to OpenInteract2 as a CMS in his post.. I personally don't see OI2 as a CMS, but an application framework. These are two quite separate things in my opinnion.. You can build a CMS on top of OI2 but I think that OI2 should not even strive to be in itself a CMS. This doesn't make it wrong to design a new HTML widget set for OI2, but I think we should keep in mind that OI2 as an application framework does not impose any specific template engine to the developer. How are we supposed to distribute html widgets which are independent to templating engine? Ofcourse we can implement these templates to only one engine, for example TT2, as a base package, but this raises an even more interesting question: What are base packages for? Are they trying to implement: * a CMS on top of OI2? * a base for a CMS to grow on top of OI2? * a generic but technology specific (TT2 and WWW) base for applications? * a generic base for applications? * a base for Chris' blog? (;)) What if somebody builds an application with OI2 which is not a CMS? And why should we even be doing yet another CMS or even a customizable CMS engine? And as AJAX is now a hot topic - what if somebody would want to use OI2 just as a AJAX backbone (for which it would suit quite well in my opinnion), what role would the base packages play? So what is OI2 and what is the purpose of base packages in your opinnion? - Antti PS. This relates somewhat to the JIRA issue to allow creating an website wihout base packages and I will comment on that more after this discussion :) |
From: Salve J N. <sj...@pv...> - 2005-06-29 18:09:33
|
[Cc: to Chris Winters and the dev-list, so everyone gets to know what we're up to. The topic is an OI2 version of Jeff's non-sucking CSS-only forms that he made available at <http://jeffhowden.com/code/css/forms/>] Jeff, Suddenly, Jeff Howden uttered: >=20 >> <><><><><><><><><><><><><><><><><><><><><><><><><><><><>< >> From: Salve J Nilsen [mailto:sj...@pv...] >> >> I'm in the process of creating a new set of templates >> for an Open Source CMS system called OpenInteract2[1], >> and would very much like to base them on your work... >> >> Would you allow me to do that? >> <><><><><><><><><><><><><><><><><><><><><><><><><><><><>< > > Yes, with two caveats. First, I'd like to be involved in the process.=20 > Second, I'd like to be given credit. Sure! If you have the time to volunteer, then that would be great! (And=20 all credit you're due, you shall recieve. ;-) > I'm not necessarily volunteering to html-code/skin every single form in= =20 > the system, but I am volunteering to build the initial "all cases=20 > visible" sample form to an approved design spec, including upgrading the= =20 > CSS in my current example to handle any new layout requirements the=20 > system/design requires. That sounds OK with me. (It's actually the way I'd like it too. :) To give you some background, you can have a look at our initial thoughts=20 at <http://sourceforge.net/mailarchive/message.php?msg_id=3D11059887>. Feel= =20 free to join the list and introduce yourself! We'd be more than happy to=20 discuss details with you. We haven't created any formal requirements, but I've written down some of= =20 my thoughts on the issue below. Feel free to comment and improve. :) --=3D=3Do=3D=3D-- Forms/widgets requirements: Basically, we need the following "widgets" (which is generally the same as= =20 "forms", except that one widget can consist of several related form=20 elements), in addition to the ones you've created already: * A "date selection" widget, consisting of three <select> dropdown lists (year, month, day). I'd like to replace this one with a proper calendar widget, sometime. * If it's feasible (and you have the time), a "multiple select" widget like this (use a fixed-width font to see the ascii=ADdrawing): +--------+ +--------+ |foo | |bah | |bar | [>>] |quux | |baz | [->] | | |bom | [<-] | | | | [<<] | | | | | | +--------+ +--------+ Where the [>>] and [<<] buttons transfer all <option>s from one <select> box to the other, and [<-] and [->] transfer just one at a time. You don't have to bother with the JavaScript details (we already have that covered), just make it look OK. * We need a widget that can edit hirearchical data in an easy and sensible way. I have a couple of ideas if you're interested in looking at this, but if you're not, then that's fine too. :) * If you still have too little to do, then "View"-versions of the widgets would be nice. Especially for list-type, tabular and hierarchical data. * Others? Other features that would be nice: * Some minimal/clean HTML-only tabs, similar to the feature described at <http://www.w3.org/Style/Examples/007/target.html>, that work nicely with the content area. * An extra-wide textarea, which could be used with WYSIWYG HTML editors like FCKeditor. <http://www.fckeditor.net/> * A proper calendar widget, e.g. a lightweight version of <http://www.dynarch.com/projects/calendar/> CSS/looks/layout requirements: * A clean, minimal design. There's no point in making lots of fancy features and graphics, just enough to make it neat and usable. It's more importnant that the people who'd like to use OI2 can change it without much effort. * All CSS color information should be contained in a seperate CSS file - to make it easy for other webdesigners to create color schemes. CSS related to the forms must be placed in a seperate file too, for easy access/cascading. Likewise for page structure and menus. An example set of CSS files, may be: - default-layout.css - default-menus.css - default-content.css - default-forms.css These should be nicely overridable by appending new CSS files to the CSS @import list. (And thus we achieve "cascading" :) * Looks: The traditional page layout for OI1 and OI2 has been two columns (as far as I know): |<------------------ browser page width ---------------->| |<---------- variable-width -------->| |<- fixed-width ->| | content | | menus | I'd like to change this to a two/three-column layout: |<- fixed ->| |<----- variable-width ----->| |<- fixed ->| | menus | | content | | OPTIONAL | | | | | | menus | Without the optional menus, the columns should look like this: |<- fixed ->| |<------------- variable-width ----------->| The optional menus column is for application "toolboxes" that could contain almost anyting (they may be subject to access restrictions, that's why they're "optional"). The left menu column is for hirearchical lists and/or menus. * The way you structured your forms is a great start. The only thing that could be improved, is to somehow make them variable-width, so they look good in (or even fit well into) the content column: |<--------------------- content column ---------------------->| |<- label ->| |<- form widgets or comments ->| |<- info-box ->| | | | variable-width, with | | | | | | optional help link | | | We also need space on the right side of each form element for an optional [help] link, similar to this: [<a class=3D"help" href=3D"/some/help/url" title=3D"A short help text or explanation">?</a>] * It would be nice if all CSS measurements were in em's and not px'en, so that page scaling works better (increasing the text size in your browser). * The page should look good when serialised (e.g. when turning off CSS), with the left menu columns showing first, then the content, and then the optional menus last. The forms and content must make sense when you look at it serialised, and read out the text aloud. * Likewise, everything must work flawlessly without javascript. I hope these "requirements" aren't too difficult. Are you up for it, Jeff? :-) - Salve --=20 #!/usr/bin/perl sub AUTOLOAD{$AUTOLOAD=3D~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua = Nilsen getc DATA}$"=3D"'};&{'";@_=3Dunpack("C*",unpack("u*",':4@,$'.# <sjn@foo= =2Eno> '2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}"; __END__ is near= ! :) |
From: <an...@io...> - 2005-06-29 08:27:07
|
Chris Winters wrote: > So if you're creating actions in by themselves without a request > available it should just do the right thing. Are you not seeing this? Yes this was one of the things i noticed when I really started working on what I was doing. Even in the actionresolver worked without a request, which was nice :) Anyway I had to do some tweaks of my own to get things working, since I had to make the same action to work while using a normal request, while being called from an another request with the user privileges and also while being called without a given request or a user at all, skipping all securities. The problem was that I needed values that were normally acquired using CTX but couldn't use CTX, since it had the state my initial action used and I needed a different state to run my action correctly. In the end I just added some extra accessors to my base Action class and set all the needed values there already in the actionresolver so it didn't have to call CTX (for other than lookups) at all when executed. Ideally (for my use) actionresolver would, in addition to what it does now, determine the _actual_ task, store additional url parameters to the action instead of the request and assign these parameters to accessors based on url_additional config. It could possibly even copy the request parameters to the action if request exists (I didn't need this myself this time). I personally store also the current language to the action and use that language for _msg calls, but I'm not sure if this is a common need. Maybe a good approach, at least for request params, would be to allow assigning this data to action's accessors and if they are not set, then try to fetch them from the request? Anyway all this data should be accessible from actions methods. I'm really not sure how vital this separation would be in the common use, but it might also make the structure easier to understand if actions were more self contained.. maybe ;) By the way, assigning url_additional automatically according to configuration is a brilliant idea in many ways :) I just started to think of it more and concluded that if the task could be determined before execute then we could assign url_additional before execute, we possibly wouldn't need the additional url parameters in action anymore, thus separating us from the request.. nice :) >> Also after this, could it be possible to find out the task and >> additional parameters before execute? > > This is a good idea, although we'll have to add a couple more > properties so that we don't recheck the task validity and reassign > params. (Not a big deal.). Did you create a JIRA task for this? Well I was not, and still am not sure of the actual things that should be done ;) So I prefer discussing them instead of creating misinformed and stupid JIRA issues ;) - Antti |
From: <an...@io...> - 2005-06-28 20:16:56
|
Nice to hear from you Chris! :) I didn't realise I had send that many mails - huh.. I feel like I'm flooded with the replies even though the mails I personally wrote were even longer, so I can't imagine how you managed to handle those in such a short time :) Well given the amount of sole crap I wrote too hastily (which I since discovered while acually doing stuff and not just rolling around in thoughts and browsing code), the fact that you know OI2 "a bit better" and are a native english speaker might have something to do with that - but still I do give you a huge credit for what you managed to do :) But now for the actual stuff - I'll keep the emails separate since they handle different areas (and I don't probably have the time to answer them all just now). >> But I'm still not sure about the error on lookup failure.. > > It's tricky: throwing an exception when you cannot find an action > makes for nice execution flow -- you can just catch the exception at > a higher level, and if you're writing code where you're actively > looking for an action it's pretty easy to just catch the exception. Yes that is true, but the problem is that the error gets logged anyway since the exception is always thrown after: $log_act->error( $msg ); > However, I agree that looking up an action might not be the best > place for an exception (conceptually speaking). We'd have to do quite > a bit of retrofitting to make this happen... I dunno, has this > bothered anyone else? Well in my opinnion it's a difference in how you see the purpose of the function. If you see it just as a means to change a known name to the corresponding action object, then throwing an exception is a good idea when this turns out not to be possible. On the other hand if you see it as a function to look up and return the action that is registered for the given name, then it would be reasonable to just quietly return nothing if there was no actual failure but the name jst wasn't registered to any acions. I personally don't think that you should actually change the logic and get rid of exceptions since they are a really handy way of doing things. I just don't want a mandatory error in my logs when it happens :) Anyway for me "lookup_action" somewhat sounds like it would be the latter one. I might be wrong here since I'm not a native speaker. - Antti |
From: Chris W. <ch...@cw...> - 2005-06-28 15:30:41
|
On Jun 19, 2005, at 11:01 AM, Antti M V=E4h=E4kotam=E4ki wrote: > After a good night sleep I came to the conclusion that maybe =20 > providing a way not to preload everything is not very urgent and it =20= > might be good to delay it for a 2.x release. This has been my general thought as well. However... your points =20 about loading/creating actions at startup might be solved fairly =20 elegantly with a lazy loading scheme. For instance, in OI2 action we =20 have a name -> prototype mapping. Whenever we get a request for a new=20 () action we grab the prototype, clone it, and assign all the =20 inbound parameters to it. (So new() actually acts like a factory, but =20= it's hidden.) There's nothing stopping us from replacing the prototype in that map =20 with a lazy loading routine. On the first access it will go through =20 the same functions currently in OI2::Setup::InitializeActions (which =20 is fairly minimal). Doing this for SPOPS is much trickier (and probably undoable) because =20= of the dependencies -- if an object contains other objects we need to =20= make sure the contained is loaded, and if the contained contains =20 other objects we need to ensure THAT is loaded.... yuck. > ... > I'm not really sure if OI2 will ever be really usable with CGI =20 > though. Even if the required initialization could be dropped =20 > somewhere close to 25 Mb, after leaving the 7 mb of mod_perl =20 > apache, it still leaves 18 Mb of modules to be initialized on each =20 > request. But it would still be nice to have a bit smaller apache =20 > threads when having multiple OI2 installations on the same machine =20 > and use CGI when developing, so that one would not have to restart =20 > apache after each change. I agree -- CGI compatibility is interesting for development (you =20 don't need to restart Apache with every change) and for small-traffic =20= internal/individual sites can be usable. But not much more than that. Regarding restarting Apache, this is very difficult due to SPOPS and =20 the fact that it generates code at runtime. There's been a =20 longstanding request to store the generated code into modules on the =20 filesystem and I think that would solve the difficult reload issue. ...then again, we do runtime initialization of other parts of the =20 system as well. For instance, the above action-creation stuff =20 wouldn't do the right thing if you modified the action class with =20 Apache::Reload because we'd still have the prototype stored... ...then again, since this is a development vs. production issue, =20 maybe we can make flaggable the ability to initialize actions at =20 startup, or ever. So every time you get a new() action it does all =20 the initialization stuff every time. Mulling over it a bit more I =20 think this is a good option. Time to create a JIRA task... Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2005-06-28 15:17:18
|
On Jun 18, 2005, at 11:04 PM, Antti M V=E4h=E4kotam=E4ki wrote: > Hello everyone :) It's been pretty quiet lately, Sorry about that. I've been kind of hibernating -- lots of RealLife =20 stuff in the way, plus I have an interesting job now which eats up =20 more brain cycles. I'll get into the preloading stuff in your follow-up... Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2005-06-28 15:13:20
|
On Jun 2, 2005, at 5:49 PM, Antti M V=E4h=E4kotam=E4ki wrote: ... > A quick look in the Action class seems to indicate that relatively =20 > few places in the action depend on CTX->request but they are vital =20 > parts like additional assigning, language handle (and thus $action-=20 > >_msg), message passing from request, checking cache (because of an =20= > admin check and cache params in request) and fetching parameters =20 > from request. Actually in most of these places (except the cache) and an explicit =20 call (like param_from_request()) we do a CTX->request and only if it =20 returns something use it. So in execute() we have: my $request =3D CTX->request; if ( $request ) { ... do stuff with $request.... So if you're creating actions in by themselves without a request =20 available it should just do the right thing. Are you not seeing this? > .... > Also after this, could it be possible to find out the task and =20 > additional parameters before execute? > Now they are all being gathered in execute and it is thus pretty =20 > hard to do any security checks, or anything else, before the =20 > determined task is executed. So when you create an Action, it is =20 > pretty much a black box and you can just fire execute off and see =20 > what happens, since you can't know which task it chooses to execute =20= > and thus which additional parameters it will have set.. This is a good idea, although we'll have to add a couple more =20 properties so that we don't recheck the task validity and reassign =20 params. (Not a big deal.). Did you create a JIRA task for this? Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2005-06-28 15:03:40
|
On May 26, 2005, at 9:51 AM, Antti V=E4h=E4kotam=E4ki wrote: > Oh. I just noticed that there was a url_none which can be used to =20 > prevent action from being executed directly by a request. No need =20 > for a none-controller then :) Yeah. > But I'm still not sure about the error on lookup failure.. It's tricky: throwing an exception when you cannot find an action =20 makes for nice execution flow -- you can just catch the exception at =20 a higher level, and if you're writing code where you're actively =20 looking for an action it's pretty easy to just catch the exception. However, I agree that looking up an action might not be the best =20 place for an exception (conceptually speaking). We'd have to do quite =20= a bit of retrofitting to make this happen... I dunno, has this =20 bothered anyone else? Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2005-06-27 19:00:38
|
On Jun 24, 2005, at 11:28 AM, Perrin Harkins wrote: > ... > By the way, do others have problems with oi2_daemon not letting go of > sockets immediately after you kill it, so you can't restart it right > away? I haven't heard about this before, but I'll put the 'ReuseAddr = 1' entry into CVS if that seems to work for people. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2005-06-27 18:59:24
|
On Jun 24, 2005, at 4:34 AM, Perrin Harkins wrote: > Apologies for the newbie question but... How do the rest of you > work on > OI2 packages? Do you keep exporting and installing them every time > you > make a change, or do you edit them in place after the initial install? > I'm assuming the latter, but the docs seem to suggest one should > install > it again every time. > > Newbie questions are ok, particularly from people working on MVC web framework comparisons :-) As Antti said, I tend to work on chunks of functionality in-place and then copy the changes back to the package source directory with 'oi2_manage update_package'. The 'update_package' function was specifically implemented so you didn't have to go back-and-forth so often. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: <an...@io...> - 2005-06-24 20:39:01
|
> By the way, do others have problems with oi2_daemon not letting go of > sockets immediately after you kill it, so you can't restart it right > away? I think you can fix this by adding: ReuseAddr = 1 in the [socket] section of your oi2_daemon.ini. I think it would be pretty safe to set this as default or at least commented out in the configuration file. - Antti |
From: Perrin H. <pe...@el...> - 2005-06-24 15:28:27
|
On Fri, 2005-06-24 at 14:31 +0200, Kutter Martin wrote: > Actually, I keep my packages in a CVS repository and edit them on my client > machine. I've just writeen a quick-hack script shell script which exports > them as OI2 package, copies 'em via scp to the server, calls oi2_manage > install_package and restarts the httpd. > > I would strongly discourage in-place editing - you lose the consistent state > a oi2 package normally provides. But you edit them in place on your client machine? I don't mind extra steps for going to production, and restarting mod_perl is fine too, but I don't want to have to do the oi2_manage mambo every time I edit a file. By the way, do others have problems with oi2_daemon not letting go of sockets immediately after you kill it, so you can't restart it right away? - Perrin |
From: Kutter M. <mar...@si...> - 2005-06-24 12:31:57
|
Hi Perrin, Actually, I keep my packages in a CVS repository and edit them on my = client machine. I've just writeen a quick-hack script shell script which = exports them as OI2 package, copies 'em via scp to the server, calls oi2_manage install_package and restarts the httpd. I would strongly discourage in-place editing - you lose the consistent = state a oi2 package normally provides. Regards, Martin Kutter > -----Urspr=FCngliche Nachricht----- > Von: ope...@li...=20 > [mailto:ope...@li...] Im=20 > Auftrag von Perrin Harkins > Gesendet: Freitag, 24. Juni 2005 10:34 > An: ope...@li... > Betreff: [Openinteract-dev] working on packages in place >=20 > Apologies for the newbie question but... How do the rest of=20 > you work on > OI2 packages? Do you keep exporting and installing them=20 > every time you > make a change, or do you edit them in place after the initial = install? > I'm assuming the latter, but the docs seem to suggest one=20 > should install > it again every time. >=20 > - Perrin >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration = Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick > _______________________________________________ > openinteract-dev mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openinteract-dev >=20 |
From:
<ant...@he...> - 2005-06-24 12:13:03
|
I have heard that Chris modifies the packages in the website and uses oi2manage update_package to copy the changes made back to the package. I personally have not yet adopted this and do my updates with a script that does remove and install ( + our custom data manipulations) for the package.. - Antti |