[TYPO3-ect] IRC chatlog of 4th of August

[R. van Twisk]

[00:04] derjoerg (n=Miranda at 199.42.240.136) joined #typo3-ect.
[05:31] kraftb (i=kraftb at gateway/web/cgi-irc/t3chat.think-open.org/unlabeled) joined #typo3-ect.
[06:34] derjoerg (n=Miranda at 199.42.240.136) left irc: "Miranda IM! Smaller, Faster, Easier. http://miranda-im.org"
[07:15] Ries (n=Ries at 200.63.220.5) joined #typo3-ect.
[07:46] t3elmar (n=elmar at mail.solarpraxis.de) joined #typo3-ect.
[07:48] <t3elmar> Hallo,
[07:49] <t3elmar> anybody here today. I will be here within 14 minutes. Elmar
[08:02] <t3elmar> back
[08:11] <Ries> Hey t3elmar
[08:12] <t3elmar> Hi Ries
[08:12] <Ries> How are you doing?
[08:12] <t3elmar> To much work
[08:12] <t3elmar> as usual
[08:13] <Ries> yesterday evening I  was testing a SSO solution for a client of mine.. it worked pritty good... However we do need to do some additional testing...
[08:13] <t3elmar> Looks like a lazy afternoon for ECT  :-) 
[08:14] <t3elmar> What do you think about global categories?
[08:16] <Ries> I think what are there.....
[08:16] <t3elmar> Yeah I also work currently on login. Typical srfeuserrgister.
[08:16] <Ries> what are these....
[08:16] <Ries> In my case in need to authentificate users comming from various places on a intranet, the intranet is as big as the USA though...
[08:17] <Ries> Typo3 is our main portal, with a couple of underlaying java applications like pentaho for sales reporting
[08:18] <t3elmar> Not so many people use TYPO3 in this dynamic way like you do ...
[08:19] <Ries> Not really.... But it is good fun, using LDAP java and typo3 all together in one big website....
[08:20] <Ries> if I can I try to to the special cases.... I am not so interested in yet a other company website..... However I do take that work since it generales casche  :) 
[08:20] <Ries> It's a interesting client....
[08:21] <t3elmar> You need to set up the same design for many applications I guess
[08:22] <t3elmar> Did you discover possibiltities to use common templates or CSS for different applications?
[08:22] Jan-Hendrik (n=jhh at 213.203.253.66) joined #typo3-ect.
[08:23] <t3elmar> Hello Jan-Hendrik,
[08:23] <Jan-Hendrik> hi elmar...
[08:23] <t3elmar> back from the east?
[08:23] <Jan-Hendrik> yes  :)  was great... but the way back was a pain, took as >30 hours
[08:24] <t3elmar> So what did you do?
[08:25] <Jan-Hendrik> discussion typo3 work of course  :-) 
[08:25] <Jan-Hendrik> our flights from mailand to düsseldorf have been canceled....
[08:25] <t3elmar> of course
[08:25] thomas-t3u (n=thomas at designnet.work.de) joined #typo3-ect.
[08:26] <t3elmar> I would take the Orient Express ...
[08:26] <Jan-Hendrik> no flights going that direction, amsterdam, frankfurt, berlin... all canceled... night in hotel, next day, no other chance to get to düsseldorf... so we hired a car, which broke in switzerland...
[08:26] <Jan-Hendrik> we didn't get bored  ;) 
[08:27] <t3elmar> Hello thomas-t3u
[08:27] <thomas-t3u> Hello
[08:27] <Jan-Hendrik> but hey... there is a sceduled time on saturday I will work on certain concepts ect relaterd. it didn't work out the flexible way, just sometime in between, so I finally fixed the time which can not be booked by someone else  :-) 
[08:28] <t3elmar> Jan-Hendrik, what about the ideas of caching objects?
[08:29] <t3elmar> Did you get the project you would need it for?
[08:30] <t3elmar> Hello thomas-t34 did you finish the linklist checks?
[08:32] <thomas-t3u> i don't know because i didn't made the test
[08:32] <thomas-t3u> it was done by wolfgang
[08:32] <thomas-t3u> i talked to him on tuesday
[08:32] <thomas-t3u> the deadline was today.
[08:33] <t3elmar> So it is done now.
[08:33] <thomas-t3u> I hope so
[08:33] <Jan-Hendrik> caching... had those ideas:
[08:34] <Jan-Hendrik> I did work on it, and will finish that on saturday as the first draft
[08:35] <Jan-Hendrik> the project is still not decided yet
[08:35] <Jan-Hendrik> but the concepts seem interesting anyway
[08:35] <Jan-Hendrik> I guess it could work on. I might be able to check a few things on saturday that I can make sure it's working the way I have in mind
[08:36] <Jan-Hendrik> this is the one topic I want to get done on saturday, the other one is the TER-subversion-connection with closed usergroup support
[08:36] <Jan-Hendrik> I send it around as soon as its done
[08:37] <t3elmar> If I rember right from Java you could give any bean a lifetime,
[08:38] <t3elmar> It could be global or bound to a user, to a request etc.
[08:39] <t3elmar> I guess cached objects need some informations like this.
[08:39] <Jan-Hendrik> yes, some sort of metadata
[08:39] <Jan-Hendrik> in typo3, there is something like that already:
[08:39] <t3elmar> This metadata is missing for existing extensions ...
[08:40] <Jan-Hendrik> the cacherecords are connected to some sort of meta info which contain usergroup information and anything, which is connected to conditions in typoscript
[08:40] <Jan-Hendrik> so if content is cached, it's stored in different versions related to usergroup and conditions
[08:40] <Jan-Hendrik> you get different versions of the same thing, which is good this way
[08:40] <t3elmar> sounds flexible
[08:41] <Jan-Hendrik> you'd have to extend it in some ways so that it also keeps track of certain livetimes
[08:41] <Jan-Hendrik> it has to be changed in some ways, I see 2 as the most important, if you just want to extend the current system. for more performance gain you'd have to rethink concept in more detail:
[08:41] <t3elmar> The TS way you can add meta data to any extension you like.
[08:42] <Jan-Hendrik> 1: you could add an option for all content elements, which could include livetime... 10 = COA; 10.livetime = 4m
[08:42] <Jan-Hendrik> 2: you cache those individual snippets, that the livetime of individual snippets can be considered seperatly
[08:44] <t3elmar> What is the difference?
[08:44] <Jan-Hendrik> if you do it for all content elements, that would probably too much work for the caching mechanism for delivery of cached pages, so it slows down the process. you might instead add a new content element like COA but including a livetime setting. so only if that's used, the snipped is cached separatly
[08:44] <Jan-Hendrik> the difference is that you can only set livetime for a full page, with this idea, it can work on the following way:
[08:45] ckoehler (n=TheSquir at COX-66-210-91-227.coxinet.net) joined #typo3-ect.
[08:45] <Jan-Hendrik> a high traffic board can have a livetime of 5 minutes, so 100 people accessing the same page within those 5 minutes would not get aq fresh page, but a cached page... the menus, some standard content is not rendered every 5 minutes, because they got a livetime of like 1 day or so
[08:46] <ckoehler> sorry guys, times confuse me, I am here now
[08:47] <Ries> That is a bit dangerous Jan-Hendrik I run a community site... and when somebody posts something.... it needs to be displayed right away....
[08:47] <t3elmar> I think this method bound to a page has the same disadvantages like the current system.
[08:47] <Jan-Hendrik> you could actualy get somethiong like that done in an easy way through PHP_SCRIPT_EXT, which does not load TS engine, but could implement it's caching
[08:47] <t3elmar> Hello ckoehler!
[08:47] <Ries> I like the idea of cache times... that can sometimes be extreemly helpfull, however core should also beable to ask a extension 'Do you have new content' when it returns FALSE then not... TRUE mean call mean and generate new content
[08:48] <t3elmar> I would think of recursive caching that is possible on any level of the TS tree
[08:49] <Ries> call main function, sorry.... At LTG we also have one other concept (build already) that is extreeml late calling of extensions... which can have the complete page in cache except some simple snippets like username...
[08:49] <t3elmar> so static content is cached, while the whole page can be dynamically updated.
[08:49] <Jan-Hendrik> ries: you are right. but you could also control it by some api you could have... delete cache in some ways. actualy, there is reg1 as key you can use already
[08:50] <Ries> Jan-Hendrik: The problem is that (in my case) I don't want to delete the cache of the page I am on, but on a other page where the content is used...
[08:50] <Jan-Hendrik> the problem is, that if you have dynamic content... do you need TS engine, or can there be some quick way of doing things.
[08:50] <Jan-Hendrik> that's no problem:
[08:51] <Jan-Hendrik> the reg1 key is just an identifyer, you can use for finding the relevant records
[08:53] <Ries> I need to go to work... but be back in 10 mins
[08:54] <t3elmar> Ok let ckoehler report from the forms project.
[08:55] <t3elmar> Sorry for my last weeks absence. It was a little chaotic here last Friday.
[08:55] <Jan-Hendrik> just to pop in in between... for svn.t3.digitaldistrict.de, I removed access to tickets, wiki edit for anonymous users, as spam has been added to the ticket list
[08:58] <t3elmar> Christoph seems to be absent
[08:58] <Ries> am I in again?
[08:59] <t3elmar> The trac of the sources have already been a big helpt to me this week
[09:00] <ckoehler> ah sorry
[09:00] <ckoehler> was gone for a minute
[09:00] <ckoehler> forms project
[09:00] <ckoehler> had a slow week last week
[09:00] <ckoehler> and didn't have a meeting
[09:00] <ckoehler> but code is full on its way
[09:00] <ckoehler> form generating is already possible nicely, with labels and all that
[09:01] <t3elmar>  a fast week the week before  :-) 
[09:01] <ckoehler> the source has an example index.php file
[09:01] <ckoehler> and this week, too. David is adding documentation, and I added labels to the forms
[09:01] <ckoehler> about the spam on trac, I asked everyone in the project to give me their username and encrypted password
[09:01] <t3elmar> http://svn.t3.digitaldistrict.de/cgi-bin/trac.cgi/browser/typo3xdev/tx_forms/trunk/class.tx_forms.php
[09:01] <Jan-Hendrik> I have had a look at what's going on partly, and it looks promising. I have withdrawn my active participation for now for the forms, as I just don't manage to be active in that area. just not to promise anything which I can not hold. I will rethink in 2 weeks, makes more sense
[09:01] <ckoehler> already got one, plus mine, so you will get a list of those
[09:02] <Jan-Hendrik> just send them, and I'll add them. no need to wait for the whole list...
[09:03] <ckoehler> will do
[09:03] <ckoehler> sec, phone
[09:03] <t3elmar> do you think a function for the label tag would belong to the base class?
[09:04] <ckoehler> hm
[09:04] <ckoehler> could
[09:04] <ckoehler> but there really isn't any need for it
[09:04] <ckoehler> labels by definition belong to a form
[09:04] <ckoehler> no form, no label
[09:04] <Jan-Hendrik> well, the basic lib does generate forms...
[09:05] <Jan-Hendrik> exactly :D
[09:05] <ckoehler> yeah  :) 
[09:05] <ckoehler> so I guess it's not necessary
[09:05] <Jan-Hendrik> but onb the other way... what is layer 2 supposed to do? it could be implemented there... logi level1, layout level2
[09:05] <ckoehler> either way, mario and jeff were working on validation but haven't coded yet
[09:05] <ckoehler> what?
[09:06] <ckoehler> what are the layers?
[09:06] <Jan-Hendrik> base class, advanced class, however you name it
[09:06] <ckoehler> well
[09:06] <ckoehler> let me explain how I imagine this whole thing
[09:06] <ckoehler> we have class tx_forms
[09:06] <ckoehler> that generates forms
[09:06] <ckoehler> using tx_forms_elements
[09:07] <ckoehler> which the user or dev doesn't need to know about
[09:07] <ckoehler> that's just how we render things internally
[09:07] <ckoehler> then we will have a validation class
[09:07] <ckoehler> and to pull tx_forms and tx_forms_validation or whatever together, the dev can write a controller
[09:07] <ckoehler> to automatically generate forms
[09:07] <ckoehler> I imagine we will probably provide at least a controller to render from TCA
[09:08] <ckoehler> maybe one that uses an array to render a form
[09:08] <ckoehler> that can be configured with TS or however
[09:08] <ckoehler> if the dev needs something special, he can code it himself
[09:08] <ckoehler> using forms and validation
[09:08] <ckoehler> the validation class will also be extendable
[09:09] <ckoehler> so the dev can override or add validation methods
[09:09] <ckoehler> and if they are any good and the dev tells us about them, we can add them to the class and distribute it to everyone
[09:09] <ckoehler> that's my vision so far
[09:09] <ckoehler> we still need to talk about how to connect the forms and validation and do some more complicated things, but that will be later
[09:10] <ckoehler> once the forms class is complete, I will start helping with validation
[09:10] <Jan-Hendrik> sounds good, and about what I remembered so far  :-) 
[09:10] <ckoehler> once those two are complete, we will connect them both with some kind of controller
[09:10] <ckoehler> probably a TCA one
[09:10] <ckoehler> maybe we will start with something simpler
[09:10] <ckoehler> remains to be seen
[09:10] <Jan-Hendrik> I will have a closer look at what has been done. it seems as if a few different controlers would make a lot of sense
[09:11] <ckoehler> I think that's about it
[09:11] <ckoehler> yeah that's what I think, too
[09:11] <ckoehler> provide one or two standard ones
[09:11] <ckoehler> but let the dev make their own
[09:12] <t3elmar> In a javabean a form is is persistant object that combines the form elements and the data untill all data is validated.
[09:13] <ckoehler> well
[09:13] <ckoehler> the problem is this:
[09:13] <ckoehler> in java, objects do stick around
[09:14] <t3elmar> The interesting question is this is if it is all part of the view or if it is already a mixture of model and view.
[09:14] <ckoehler> in php, they don't. you create them, the page gets rendered, you submit the form, they get created from scratch, you render something again
[09:14] <ckoehler> the model is the underlying data
[09:14] <ckoehler> these forms don't have any data yet
[09:14] <t3elmar> But this question is rather philosophical. I tend to regard such a construction as part of the view until it is deliverd to the model after validation.
[09:15] <ckoehler> neither data nor label
[09:15] <ckoehler> yeah
[09:15] <ckoehler> we really don't do the model though
[09:15] <ckoehler> Typo3 CoreData" would be nice, but no
[09:15] <ckoehler> at least not yet
[09:15] <ckoehler> so we supply the view = forms
[09:15] <ckoehler> we supply some controllers
[09:16] <ckoehler> and the model, the data, comes from somewhere else
[09:16] <ckoehler> well
[09:16] <ckoehler> I guess we work on it some through validation
[09:16] <ckoehler> but that is only part of it
[09:16] <ckoehler> the whole data storing part is huge and not our problem
[09:17] <ckoehler> at least yet, like I said
[09:17] <t3elmar> PHP hasn't this persistence of Java, but there is the possibility to stream a the database/session until the next request with updated data comes in.
[09:18] <ckoehler> what do you mean with stream the database or session?
[09:19] <t3elmar> I like this idea of storing the object into the session very much. I still haven't worked wit it, but it behaves much like a classical visual computer programm.
[09:19] <ckoehler> hm
[09:19] <ckoehler> that could be a possibility
[09:20] <t3elmar> To use the form class in the way I am just talking of is part of the 3 or 4 level Jah-Hendrik mentioned.
[09:20] ingorenner (n=chatzill at port-212-202-126-63.static.qsc.de) joined #typo3-ect.
[09:20] Ries (n=Ries at 200.63.220.5) left #typo3-ect.
[09:20] Ries (n=Ries at 200.63.220.5) joined #typo3-ect.
[09:20] <Jan-Hendrik> how much of the for itself (HTML) is part of the lib, and how much can be controlled?
[09:21] <ckoehler> what?
[09:21] <ckoehler> how much of what?
[09:21] <t3elmar> Jan Welzel pointet to: http://java.sun.com/javaee/javaserverfaces/download.html with discribes this method with diagrams.
[09:23] <ckoehler> Are you asking about how much html is part of the lib and how much you can do yourself?
[09:25] <Jan-Hendrik> how much of the html... <input type...
[09:25] <Jan-Hendrik> yes
[09:25] <ckoehler> okay
[09:25] <ckoehler> well
[09:25] <ckoehler> the form tags are hardcoded
[09:25] <ckoehler> obviously
[09:25] <Jan-Hendrik> the whole tag i guess
[09:26] <ckoehler> yeah, but you have full control over all its attributes
[09:26] <ckoehler> and that's it
[09:26] <Jan-Hendrik> i guess we would not have to change xhtmlformat to something else in the near future, so I guess that's ok  ;) 
[09:26] <ckoehler> the final render of a form field is the label tag and the field tag itself
[09:26] <ckoehler> all forms validate xhtml 1,1
[09:26] <ckoehler> 1.1
[09:27] <ckoehler> and if not now, they will
[09:27] <ckoehler> that's a big factor
[09:27] <ckoehler> everything else you can control somehow
[09:27] <ckoehler>  we were also thinking about some kind of templating
[09:28] <ckoehler> or at least some default way of rendering a whole form
[09:28] <Jan-Hendrik> the idea I had:
[09:28] <ckoehler> because the form class' render() function just lines them up, no linebreaks, and that's not ideal
[09:28] <Jan-Hendrik> you might want to render forms for other cases like PDF, in this case they are rendered differently
[09:28] <ckoehler> hehe
[09:28] <ckoehler> no, sorry, at least not yet
[09:28] <Jan-Hendrik> just ideas  ;) 
[09:29] <ckoehler> yeah eventually  :) 
[09:29] <ckoehler> but right now I have 4 people actively thinking about stuff, including me and excluding you (since you do all the server stuff, so you are a member of the team and all, don't get me wrong!)
[09:29] <ckoehler> jeff and mario haven't started on the validation yet as far as I know
[09:30] <ckoehler> since jeff is moving
[09:30] <ckoehler> so it's understandable
[09:30] <ckoehler> david has done javadocs stuff
[09:30] <Jan-Hendrik> i see
[09:30] <ckoehler> and I have done the rest, and that's awesome, but won't work once school starts
[09:30] <Jan-Hendrik> this is a problem. I'll think about it as well
[09:30] <ckoehler> so it will either grind to a halt, or we find some more people I guess
[09:30] <Jan-Hendrik> maybe we find some ideas how to make it save
[09:31] <ckoehler> that's why I wanted to get started
[09:31] <ckoehler> so someone else could take over if necessary
[09:31] <ckoehler> and build on what we already have
[09:31] <ckoehler> instead of having to start from scratch
[09:31] <ckoehler> not blaming anyone, we all have things to do
[09:31] <Jan-Hendrik> what is the status on validation exactly?
[09:32] <ckoehler> we have the concept
[09:32] <ckoehler> a class full of validation methods
[09:32] <ckoehler> we might write a wrapper later
[09:32] <ckoehler> apart from the general controller
[09:32] <ckoehler> but I want a class with just validation methods
[09:32] <ckoehler> so people can extend it
[09:32] <ckoehler> and that's it
[09:32] <ckoehler> no code
[09:33] <Jan-Hendrik> maybe some plugin method would be good
[09:33] <Jan-Hendrik> this way no xclassing or anything is needed
[09:33] <ckoehler> too complicated
[09:33] <ckoehler> I don't see what's wrong with extending a class
[09:33] <Jan-Hendrik> long term the better idea I guess... what do you do if you have two extensions extending the libs... problem
[09:34] <ckoehler> not really
[09:34] <Jan-Hendrik> index_rules of DAM do a good job, used it already, I can put together a demo at the weekend, so you know what I mean
[09:34] <ckoehler> don't several extension extend pibase?
[09:34] <ckoehler> that's not a problem
[09:34] <Jan-Hendrik> yes, but you can not make use of something which has been done in another extension easily
[09:34] <ckoehler> but maybe I am not getting the point
[09:35] <ckoehler> right
[09:35] <ckoehler> it has to be extended for that extension specifically
[09:35] <ckoehler> and that's okay
[09:35] <Jan-Hendrik> example:
[09:35] <ckoehler> that's the whole point, for those rare cases...
[09:36] <Jan-Hendrik> dam does a job, but it makes use of functionality
[09:36] <Jan-Hendrik> that functionality (index rules, adding mp3 index rule, adding ppt index rule,...) is extended via extensions
[09:36] <Jan-Hendrik> for the forms:
[09:37] <Jan-Hendrik> you could extend some processing of forms in some way, which is something you use in more extensions... in those extensions, they still make use of the standard forms-class, they do not know if things are changed....
[09:38] <ckoehler> so extend the forms validation with exts?
[09:39] <ckoehler> so if I want to build a form in my extension, I have to first write another extension to add all the validation method I want to use?
[09:39] <ckoehler> instead, I could just extend the validation class
[09:39] <ckoehler> plug my extended new class into whatever controller takes care of validation, and use my new methods
[09:39] <ckoehler> which are totally irrelevant for other extensions
[09:39] <ckoehler> if they are not, if they are useful and awesome, we add them to the main lib
[09:40] <ckoehler> maybe I am totally not getting it, but it sounds good to me
[09:41] <Jan-Hendrik> you can always do so if it is just for your own extensions...
[09:41] <Jan-Hendrik> but it's not supporting any functionality whihc you add globaly for more than one extension, that's what I am talking about
[09:42] <t3elmar> I like the factory/service pattern: The extension asks for the form class via an interface. The interface delivers either the original form class or any alteration, extension or replacement for it.
[09:43] <Jan-Hendrik> but stil you have the problem that you extend the class a couple of times, how does that work?
[09:43] <ckoehler> same way it works with the pibase class
[09:43] <Jan-Hendrik> just one extension, sure
[09:43] <ckoehler> it will be unique to the extension
[09:43] <ckoehler> right
[09:43] <ckoehler> as simple as can be
[09:44] <Jan-Hendrik> still not ideal if you have common functionaly you add for more than one extension  :) 
[09:44] <ckoehler> that should at least remain a possibility
[09:44] <Jan-Hendrik> sure, no problem with that  :) 
[09:44] <ckoehler> how many people have more than one extension?
[09:44] <ckoehler> a dozen?
[09:44] <ckoehler> I don't think it's a problem at first
[09:44] <ckoehler> later, sure, open for new things
[09:44] <Jan-Hendrik> well, dam is a good example: you did not just extend it with one index-rule, but have many, like mp3 and some others  ;) 
[09:45] <ckoehler> yeah and that's a good idea
[09:45] <Jan-Hendrik> I'll do some work on your code to show you what I mean...
[09:45] <ckoehler> but way far away
[09:45] <Jan-Hendrik> not sure
[09:45] <ckoehler> I know what you mean
[09:45] <ckoehler> if you want to do it, feel free  :) 
[09:45] <Jan-Hendrik> i am just against making things not open to anything by architecture :D
[09:46] <ckoehler> the people I know I have right now will be busy getting basic validation to work and all, so I doubt we will have that done before end of the month
[09:46] <ckoehler> we can always add stuff like that later
[09:46] <Jan-Hendrik> sure. I'll see what I get together at the weekend
[09:47] <ckoehler> but that goes deeply into T3, and I don't know how all that works
[09:47] <ckoehler> so you guys can keep the long term vision
[09:47] <ckoehler> and remind me of it every once in a while  :) 
[09:47] <ckoehler> while I get the short term stuff done
[09:47] <Jan-Hendrik> not really. the plugin thing is just 2 functions, which can be part of the lib extension. to activate it, it's just a call in localconf.php
[09:47] <ckoehler> hm
[09:47] <ckoehler> sounds easy  :) 
[09:48] <ckoehler> well
[09:48] <ckoehler> alright
[09:48] <Jan-Hendrik> I'll show you
[09:48] <ckoehler> that goes deeper into t3 than I know
[09:48] <ckoehler> so I will leave that up to you
[09:48] <Jan-Hendrik> no problem.... (it doesn't touch t3-core at all ;))
[09:49] <ckoehler>  :)  I am dumb
[09:49] <Jan-Hendrik> i guess not, otherwise you would not have maanged setting up the forms lib  ;) 
[09:49] <ckoehler> well
[09:49] <ckoehler> maybe I am t3 dumb  :) 
[09:49] <ckoehler> localconf, blabla,
[09:49] <ckoehler>  :) 
[09:50] <ckoehler> but yeah, go ahead, that sounds like a good idea
[09:50] <ckoehler> but I am all for adding good stuff to the main lib
[09:50] <t3elmar> Christoph makes the form, Jeff the Validation and Jan-Hendrik the flexibility. Good distribution if tasks, I think.
[09:50] <ckoehler> instead of having to install 30 exts to get the validation method I want
[09:50] <ckoehler> yeah it sounds pretty good!
[09:51] <ckoehler> Jan-Hendrik, I will send you an email wiht htpasswd stuff
[09:51] <ckoehler> how soon you think you can add that?
[09:52] <Jan-Hendrik> if I get it now, within minutes, if I get it after midnight, it might take a couple of hours  ;) 
[09:52] <Jan-Hendrik> seriously... I can do it quickly... it could just be that I am not working all weekend... but that's it
[09:53] <ckoehler> give me a few minutes
[09:54] <t3elmar> Coming back to "streaming" forms into the session for a quicky time simulate persistance. The right terms are serialization and unserialization.
[09:54] <t3elmar> See http://www.php.net/manual/en/function.serialize.php
[09:55] <ckoehler> Jan-Hendrik, can I send it in a pm right now? Or email?
[09:55] <Jan-Hendrik> please mail
[09:55] <ckoehler> k
[09:56] <ckoehler> t3elmar, yeah that would be possible
[09:56] <ckoehler> don't know how much data we will need and all
[09:56] <ckoehler> but that would be a possibility later
[09:56] <ckoehler> or now
[09:56] <t3elmar> That is probably the layer I have to join in,  level 3.
[09:56] <ckoehler> just have to look into it
[09:57] <ckoehler> Jan-Hendrik, k, sent
[09:58] <ckoehler> sure, feel free
[09:58] <ckoehler> I will be very happy if we can create forms, and validate some basic things, by August 21st
[10:02] <t3elmar> I will start with "level 3" not before september. I first need to focus on lib/div. We still haven't no rendering engine for it. Only plain PHP.
[10:06] <ckoehler> sounds good
[10:06] <ckoehler> we will just go from here then
[10:08] <Jan-Hendrik> i am off now, see you later...
[10:09] <t3elmar> OK. I am leaving for today ... see you
[10:09] <ckoehler> later
[10:10] t3elmar (n=elmar at mail.solarpraxis.de) left irc: "Chatzilla 0.9.75 [Firefox 1.5.0.4/2006060216]"
[10:10] Jan-Hendrik (n=jhh at 213.203.253.66) left #typo3-ect.
[10:22] ingorenner (n=chatzill at port-212-202-126-63.static.qsc.de) left #typo3-ect.
[10:22] thomas-t3u (n=thomas at designnet.work.de) left irc: Remote closed the connection
[11:11] kraftb (i=kraftb at gateway/web/cgi-irc/t3chat.think-open.org/unlabeled) left irc: "KVIrc 3.2.0 'Realia'"
[11:37] ckoehler (n=TheSquir at COX-66-210-91-227.coxinet.net) left irc: "zZzZZ"
[11:40] ckoehler (n=TheSquir at COX-66-210-91-227.coxinet.net) joined #typo3-ect.
[12:33] ckoehler (n=TheSquir at COX-66-210-91-227.coxinet.net) left irc: "zZzZZ"
[12:57] ckoehler (n=TheSquir at COX-66-210-91-227.coxinet.net) joined #typo3-ect.
[15:11] t3elmar (n=elmar at mail.solarpraxis.de) joined #typo3-ect.
[15:11] t3elmar (n=elmar at mail.solarpraxis.de) left irc: Client Quit
[16:58] Awillys (i=kvirc at bb-87-81-190-96.ukonline.co.uk) left irc: "KVIrc 3.2.0 'Realia'"
[17:09] ckoehler (n=TheSquir at COX-66-210-91-227.coxinet.net) left irc: "Leaving"
[18:30] Ries (n=Ries at 200.63.220.5) left #typo3-ect.
[00:00] --- Sat Aug  5 2006