AW: [Openinteract-dev] OI 2 testing

[<And...@Be...>]

.. Actually Dietmar and I already talked about this. Since most =
dependencies
are more towards SPOPS and the NATS framework runs w/o OI anyway it =
won`t be
a problem. I hope we can release a "public beta" of the nats framework
together will NATS-Ticket as a sample application soon. Most left to do =
is
docs and making it installable ;-)

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]=20
Gesendet: Montag, 23. Juni 2003 08:09
An: Andreas Nolte
Cc: ope...@li...
Betreff: Re: [Openinteract-dev] OI 2 testing


Andreas Nolte wrote:
> finally found the time to do some OI 2 / Beta 0 testing.
>
> First impression in short: already works great.

This is extremely valuable. Thanks a ton for taking the time.

> After this I followed the readme / Manual::Intro and setup a testing=20
> site with lwp. This all worked by the book !

Cool!

> The only spottable "error" I found in the news package: here the=20
> display of dates is not correct in the templates. It shows the class=20
> name, so I assume a deref is missing somewhere.

I'll check into this. All date fields in core packages are converted=20
automatically to DateTime objects....

> Switching on debugging als shows, that OI 2 is whining about a few=20
> classes not specifying a "date conversion format". These are classes=20
> News, ErrorObject, Page, User and ObjectAction.

...which is why this was complaining. I'll probably just put the=20
universal 'yyyy-mm-dd hh:mm:ss' in for this: I think any database=20
should be able to handle it.

> Next I tested with apache 1.3.26 / mod_perl 1.27 by switching the=20
> types in the configs. I was interested, if this would do any harm to=20
> the site or change anything in the layout - no - works w/o a problem.

hooray!

> Now I switched the DBI type from SQLite to Mysql 4.0.13, reinstalled=20
> the SQL etc -> success.

Even better -- I'd only tested with PostgreSQL (7.3 something) and=20
SQLite.

> Since this all worked to easy so far ;-), I tried to go for=20
> Apache2/mod_perl2 by registering a new factory type for the=20
> request/response classes and setting up an Apache2::OpenInteract2=20
> handler class. Basically, it turns out to be a rather small task with =

> the main "problem" being, that the mod_perl2 documentation is not=20
> ready yet.

You're very optimistic :-)

> BTW: could anyone tell me where $REQUEST_CLASS is set in Request.pm=20
> and where the get_current method in Request/Apache.pm comes from ?

During setup OI2::Context->assign_request_type() (and=20
assign_response_type() for Response.pm) calls=20
OI2::Request->set_implementation_type() with the relevant type name.=20
The type name is read from the server.ini file, although you can set=20
it afterward too.

> I fell across s.th. different, though: treads and databases ! Since=20
> mod_perl2 works with ithreads ( meaning one perl instance in every=20
> thread), which means, a shared nothing aproach is used, I did not see =

> reason for not trying the treaded worker mpm. The problem is, that in =

> perl 5.8.0 you cannot share any object across threads, so also no db=20
> connections. This also means, that you cannot use any db object from=20
> the initial thread in any other thread. Here I fell with OI2, since=20
> the db connections are made quite early, before the initial thread is =

> cloned to handle the request.
 > ...
 > Is there a chance to kick the connections and reestablish them  > in =
them
when the request is handled? At that point, you could do  > caching of =
db
connections, since you are within a separate thread.

I had to deal with this in the LWP daemon too. Before we do the fork=20
we execute the following:

     # We need to close all database handle created in the
     # initialization process so the child doesn't try to use it.
     OpenInteract2::DatasourceManager->shutdown;

In theory this would work with mp2 as well -- you'd probably execute=20
this as the last line in the startup.pl.

After seeing Artur's presentation on threads at YAPC::NA I'm curious=20
to see what other changes are necessary. I'm in the process of=20
modifying OI2::Context so that certain configuration items (action=20
table, SPOPS config info, ...) are accessed by methods alone... This=20
will make it easier to follow what's going on and also provide the=20
means to use threads::shared to share what little read/write data=20
exists in the CTX object.

> Also I tried to read a bit through the OI2 code and find it a lot =
more=20
> understandable than the OI1 code. I especially like the use of=20
> Class::Accessor and Class::Factory and the CTX singleton.

Yeah -- there shouldn't be anymore magical hashref accesses :-)

> Looking at the new News package, I found it not too different from =
the=20
> OI1 packages, which is great because it means that porting modules=20
> should not hurt too much.

It really shouldn't be too bad -- most everything is:

   - changing $R data access/methods to CTX/request/response
   - accessing action state using ->param(...) rather than passing=20
around \%p
   - calling 'generate_content()' on the action itself and passing=20
only parameter and template identifier info
   - if you're using OI::CommonHandler you'll need to move most/all=20
of the declarations into the action configuration, change some=20
method names (e.g., 'show' becomes 'display', 'display_form' and=20
'display_add'; 'edit' becomes 'update' and 'add', etc.) and modify=20
what you inherit from

> The verbose feedback of oi2_manage is also a good idea.

I think I'm going to move most of the functionality from oi2_manage=20
into a class so packages can declare tasks at runtime and allow=20
addtional parameters to be passed in... we'll see. It's MUCH easier=20
now to add tasks, report info, etc.

> In short: first impression is really great - well done Chris !

Thanks! The real test comes when you try to port NATS and other=20
modules :-)

Chris

--=20
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting =
Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly =
Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
openinteract-dev mailing list ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev