20:09:40 | Loge | lets speak of config.inc.php vars |
20:09:51 | rabol | Maybe we should use v.0.7 to prepare all modules for a OO design: By that I mean that we can re-write module to use the switch() thing of newb's proposal ? |
20:10:14 | Loge | thats allready on the way... lets make a step back |
20:10:26 | Loge | newb says we should only have db access vars in config.inc |
20:10:38 | k-fish | rabol: sure, it will/should all happen on 0.7 CVS |
20:10:46 | k-fish | Loge: seems nice. |
20:10:50 | rabol | Where should application vars be ? |
20:11:04 | Loge | rabol: the nicest thing would be a xml |
20:11:05 | k-fish | but we have to ave the other stuff somewhere. how do these get into the source? |
20:11:15 | k-fish | ah xml. ok. another buzzword :-) |
20:11:31 | Loge | something like a definition.xml for the app |
20:11:36 | Loge | (as we have for modules) |
20:11:38 | k-fish | but would be a way to go. so setup would write out that xml file, and it would get read by the app? |
20:11:41 | Loge | but with different structure |
20:11:47 | Loge | yeah |
20:12:05 | Loge | perhaps we should use a different name, cause i dont like a xml name that has different DTDs |
20:12:07 | k-fish | and the data would be stored with/in the session?!? |
20:12:11 | rabol | well.... yes and no XML is good for exchange of data but that's not what we need/waht |
20:12:11 | Loge | yeah |
20:12:17 | --- newb_away is now known as newb |
20:12:17 | Loge | why? |
20:12:21 | k-fish | hi newb |
20:12:26 | * newb back ! |
20:12:28 | Loge | hi |
20:12:49 | newb | soory guys a bit late |
20:12:53 | Loge | np |
20:12:58 | rabol | We want a definition which is 90% static ? |
20:13:06 | k-fish | rabol: not only for exchange. using xml at least gives you the chance to validate the config... |
20:13:12 | Loge | no, its not static, its just a format |
20:13:27 | rabol | But how often does the definition change ? |
20:13:37 | Loge | depends on the admin |
20:14:01 | Loge | so how about migrating config.inc.php to an xml file |
20:14:08 | Loge | and then lets talk what we should have in there |
20:14:10 | k-fish | as soon as the system is set up correctly, it should change with the next update, i'd say |
20:14:22 | rabol | hmmm a definition of a module 'only' change when the module change... or are we talking about configuration of a module ? |
20:14:37 | Loge | we talk about replacement of config.inc.php |
20:14:38 | k-fish | configguration of modules and the whole app |
20:14:45 | newb | We have to worry about the fact that all xml files can be viewed ! |
20:15:04 | Loge | ok, you mean the db password |
20:15:08 | Loge | lets encrypt it |
20:15:13 | k-fish | not if you deny serving them. but then again, that is only good when you have the rights to change such things... |
20:15:19 | rabol | I vote for a XML to define the module, and DB for configuration.... |
20:15:33 | k-fish | necrypting it would make us loose the easyness gained by using xml |
20:15:47 | newb | rabol: yes ,me too but you have to keep db connection parameters out of the db ! |
20:15:48 | Loge | kfish: ?? only the value of one tag |
20:15:58 | Loge | newb: yeah in the xml file |
20:16:05 | rabol | If we have a encrypted XML-like file it would be a great job to maintain the code to handle the XML file.... |
20:16:14 | newb | Loge: good but xml can be viewed |
20:16:16 | Loge | rabol: not encrypting the file |
20:16:25 | newb | loge: i mean served by httpd |
20:16:32 | Loge | newb: yeah but if db password is encrypted it doesnt matter |
20:17:06 | newb | Loge: reavealing infos such as db port, db user is insecure |
20:17:11 | Loge | somwthing like <dbpassword>%encrpted%</dbpassword> |
20:17:47 | k-fish | rabol: so you would put all configuration in the db? and just have the db connection data in the config file? |
20:17:52 | k-fish | sound good. |
20:18:01 | newb | k-fish: yes sounds good |
20:18:03 | rabol | k-fish: Yes |
20:18:05 | k-fish | this would make updates easy... |
20:18:31 | newb | I have wrote a note in this way in the mgw_app_class.inc |
20:18:34 | Loge | this is not an update issue |
20:18:42 | k-fish | you wouldn't have to worry about changes to the config file... |
20:18:44 | Loge | you can also maintain an xml file easily |
20:18:49 | k-fish | Loge: not yet, but in the future it will be. |
20:19:02 | rabol | I like XML but, the code to maintain XML..... I think that we can use our time on better things |
20:19:16 | Loge | rabol: hey there are parser in the world :) |
20:19:26 | k-fish | true :) |
20:19:26 | Loge | rabol: normally its damn easy to maintain a xml tree |
20:19:41 | Loge | i am not quite sure about the db saving |
20:19:46 | rabol | If we have the settings in DB, the as time gos we can have a XML class to pull it out and then use XML |
20:20:06 | Loge | rabol: why using an interim solution? |
20:20:10 | k-fish | rabol: this would mean doing work now, to throw it away later :( |
20:20:25 | Loge | ok, where are the cons of xml? |
20:20:29 | newb | Loge: you are talking about putting config.xml of modules into the db ? |
20:20:36 | Loge | newb: no |
20:20:46 | Loge | i am just talking about config.inc.xml :) |
20:20:59 | rabol | well... yes and no.... we can use our effort now to build a nice and stable application, and have the XML in mind |
20:21:07 | newb | Loge: ok, i think this file should contains only db parameters |
20:21:15 | Loge | newb: why? |
20:21:19 | k-fish | newb: and the other stuff? db? |
20:21:40 | newb | Yes, other stuff must reside in db |
20:21:41 | rabol | The problem is not that's one the problem is the code which is needed for XML |
20:21:46 | Loge | newb: why? |
20:22:06 | newb | Because such things are parameters of the app class |
20:22:08 | Loge | rabol: dont mind, its only a library to use |
20:22:23 | Loge | newb: but thats not a reason for storing in db |
20:22:33 | newb | i.e. the output html/wml etc... |
20:22:34 | Loge | please tell me real cons for xml file |
20:22:39 | rabol | well... if that's the case... I don't mind at all ;-) |
20:22:43 | Loge | wuah pk |
20:22:44 | Loge | ok |
20:22:55 | newb | Loge: because the other parameters are to be set interactively by the admin |
20:23:09 | newb | Loge: i mean, via the web |
20:23:13 | Loge | newb: ok lets see which parm should be in xml |
20:23:17 | newb | Loge: no ? |
20:23:26 | Loge | at least db stuff |
20:23:27 | k-fish | newb: the paths should stay the same, mostly |
20:23:43 | k-fish | newb: other stuff, yes |
20:23:57 | Loge | damn dont have a config.inc here, can somebody send me one? |
20:24:11 | k-fish | newb: (might change frequently, i mean) |
20:24:26 | Loge | in private channel? |
20:24:47 | rabol | Send... please remove the password ;-) |
20:24:48 | newb | k-fish: yes, paths could also be candidate for xml |
20:25:01 | Loge | rabol: ?= |
20:25:15 | Loge | rabol: just a query to me in IRC |
20:25:18 | rabol | I send you a email with config.inc |
20:25:22 | Loge | oh email |
20:25:37 | k-fish | let's see it this way: put everything that has to be changed if you move the app in the xml. everything independent of the place the app lives in, should be in the db. |
20:25:56 | Loge | hard to say independent ... db can also change |
20:26:01 | rabol | hmmm you could not accept the picture.... |
20:26:05 | k-fish | yes, this would be in file... |
20:26:44 | k-fish | paths+db+ldap -> xml, langauge+cacheing+theme+... -> db |
20:27:10 | Loge | cant see real differences of these groups :) both can change |
20:27:32 | Loge | my favourite is still everything in xml |
20:27:38 | Loge | with a good DTD |
20:27:41 | rabol | but paths+db+ldap don't change that often |
20:27:46 | k-fish | yes but the latter might change more freuquently and will still work if you move the app to another server. |
20:27:48 | Loge | this way we have a documented config file |
20:27:56 | newb | What if an admin want to change the theme via the web ? |
20:28:07 | Loge | newb: where is the problem with xml then? its easy |
20:28:20 | Loge | newb: its just a matter of file writing |
20:28:34 | k-fish | Loge: would mean you'd have to keep the file writable for the webserver process. hm ... |
20:28:38 | Loge | newb: read in XML -> manipulate -> write XML |
20:28:46 | newb | I mean an admin in a cybercoffe with not other access than http:// |
20:28:58 | Loge | newb: no matter of location |
20:29:02 | newb | newb: dumb case yes :) |
20:29:14 | Loge | tell me where the problem is in my scenario? |
20:29:35 | k-fish | after setting up MGW, I'd remove write right as far as possible. |
20:29:39 | Loge | its 8-10 lines of code with a good XML library (which we need anyway) |
20:29:49 | newb | How to change you xml files when accessed via only a simple browser |
20:29:52 | Loge | kfish: ?? |
20:30:01 | Loge | newb: the same way as setup do |
20:30:14 | k-fish | Loge: if you want to change the xml file via the web, it has to be writable by the server process. |
20:30:29 | Loge | kfish: has to be anyway during setup |
20:30:34 | Loge | kfish: same as now |
20:30:40 | k-fish | yes, but afterwards I can remove it... |
20:30:45 | k-fish | (write rights) |
20:30:47 | Loge | kfish: thats right |
20:30:53 | Loge | kfish: then you cant :) |
20:30:58 | k-fish | :/ |
20:31:12 | Loge | but i also want to modify db settings via web |
20:31:14 | Loge | so its the same |
20:31:23 | newb | Loge: i think we should restrict the info in xml to 'constants' values |
20:31:28 | --> mdelamere (~jaja@pD950CBAB.dip.t-dialin.net) has joined #moregroupware |
20:31:28 | Loge | (which we can do right now) |
20:31:35 | mdelamere | hi |
20:31:39 | newb | Hi md |
20:31:39 | Loge | newb: there are no real constant values |
20:31:56 | k-fish | don't know if that makes sense. (moidifying db via web). how do you move the db to another location? |
20:31:57 | newb | Loge: version of the app, db parameters... |
20:32:15 | k-fish | newb: i agree |
20:32:18 | newb | Loge: i mean by constants values that don't have to be changed from a release to another |
20:32:19 | Loge | kfish: perhaps you have a different name for the server now or whatever |
20:32:34 | k-fish | Loge: and that would be? |
20:32:38 | k-fish | paths? |
20:32:44 | k-fish | might change as well... |
20:33:04 | Loge | kfish: my point is, right now you can modify config.inc.php via web, also db parameter...and password changes are not unlikely |
20:33:21 | newb | k-fish: path changement or db changment have to be done by admin on LOCAL box |
20:33:22 | Loge | kfish: so we need this freedom in any way |
20:33:41 | newb | newb: offline, so putting values in xml is good |
20:33:42 | Loge | newb: yeah but why not via setup? |
20:33:53 | k-fish | newb: so no web setup again? |
20:33:57 | * k-fish is puzzled |
20:34:14 | Loge | ALL: please i need real drawbacks of XML saving |
20:34:30 | k-fish | but i'd be happy. if i need to login to to my server to change it, i can easily deal with write permissions etc... |
20:34:32 | newb | Maybe we should wrote little scenario |
20:34:42 | * Loge wouldnt mention this if he had not seen this 100x times in applications :) |
20:35:20 | Loge | kfish: ok your point is write permission |
20:35:21 | * k-fish wants to keep as little as possible writable stuff. |
20:35:32 | newb | XML saving and reading is not so easy the db saving |
20:35:47 | Loge | newb: ohhh, come on :) thats not a real argument... |
20:35:52 | newb | Loge: and xml can easily be messed up... |
20:35:56 | Loge | newb: not when you do it with regex :) |
20:36:07 | Loge | but when you take a parser then it easy |
20:36:10 | k-fish | Loge: stop. this would mean writing ouir own parser. bad |
20:36:14 | Loge | no |
20:36:17 | newb | Loge: users with notepad can put mess... |
20:36:17 | Loge | regex is bad |
20:36:19 | rabol | That the poin regex is not the solution ;-) |
20:36:40 | k-fish | ok, so we would need a parser to do xml work. |
20:36:42 | Loge | you missunderstood me |
20:36:48 | Loge | we need it anyway |
20:36:55 | Loge | thats a task : to find a good parser |
20:36:59 | k-fish | afaik, none of the parsers avail to php (out of the box) are validating anyway. |
20:37:28 | Loge | kfish: yeah, but we need a PHP based parser which doesnt need libxml or something...it shoudl work with expat |
20:37:37 | k-fish | ok |
20:37:50 | Loge | i have one, but not tested: phpDOM |
20:38:04 | Loge | ok lets speak later what fields to put in there |
20:38:05 | newb | Loge: i thought you wanted as less as php package as possible |
20:38:15 | Loge | newb: no as less as extensions |
20:38:31 | Loge | APIs or libraries (not C) are good |
20:38:35 | Loge | PHP based ones |
20:39:01 | newb | expat is not a php API |
20:39:13 | Loge | expat is compiled in per defailt |
20:39:15 | Loge | default |
20:40:01 | Loge | ok, lets go to next step |
20:40:18 | Loge | we agree that we need a xml file (lets see what we do in there later...) |
20:40:22 | newb | Loge: ok, so let's summarize the config solution as far |
20:40:26 | k-fish | 14 entries in xml category at zend.com's code gallery. should be possibnle to find something there. |
20:40:34 | k-fish | yes, summarize is good :-) |
20:41:08 | Loge | 1. we need an app definition xml file 2. talk later what we put in there 3. find an xml parser perhaps which validates |
20:41:11 | newb | but it's not me who can do that (i was late) |
20:41:11 | Loge | ok? |
20:41:24 | k-fish | ok with me |
20:41:34 | Loge | fine, then lets check index2.php |
20:41:42 | Loge | so the basic framework |
20:41:43 | newb | ok for me too |
20:41:59 | k-fish | index2.php: short open tags. bad. :-) |
20:42:08 | * k-fish is just kidding |
20:42:17 | Loge | hehe, ok we can fix this later :) |
20:42:26 | newb | Is everyone aware that having just one index.php is good ? |
20:42:27 | * k-fish wonders: why does it say: dont'use ?!? :-) |
20:42:46 | Loge | it was also on index before or? |
20:42:52 | newb | k-fish: you can use: just add mod=notes to the query string |
20:42:53 | Loge | i think its good |
20:43:05 | k-fish | newb: sounds good to me. gives clean oo out of the box. :-) |
20:43:29 | newb | So we all agree that dealing on one place is good |
20:43:36 | Loge | wait |
20:43:44 | newb | Loge: yes |
20:43:47 | Loge | you mean all request go over index? |
20:43:47 | newb | ? |
20:43:50 | Loge | this in the root? |
20:43:53 | newb | Loge: yes |
20:44:03 | Loge | ok, seems ok |
20:44:23 | newb | like that, bye bye all path mess |
20:44:24 | k-fish | (great benefit: central place where everythign else is inherited from) |
20:44:41 | Loge | where is the point in index2 where the REAL module code starts |
20:44:44 | k-fish | newb: right. that solves the path probs. cool |
20:44:47 | newb | form index2.php we include classes file from modules |
20:44:59 | Loge | i see this yeah... |
20:45:03 | Loge | and then? |
20:45:19 | newb | in index2.php the app is the main object |
20:45:24 | Loge | ok |
20:45:30 | k-fish | it gets created after the mod are loaded? |
20:45:36 | Loge | processAction! ok |
20:45:40 | newb | It could contains all the module object |
20:45:41 | Loge | thats the point |
20:45:53 | newb | or provide a module object on demand |
20:46:22 | Loge | yeah i see, lets start with all modules in the session or? |
20:46:24 | newb | I mean, we can instantiate all module object one time and have them in session |
20:46:26 | Loge | we can do benchmarks later on |
20:46:32 | newb | (in the app object) or |
20:46:51 | newb | decide to provide module object when needed |
20:47:04 | k-fish | where is the app class defined (which file)? |
20:47:06 | newb | In the /include/mgw_app_class.php |
20:47:10 | Loge | so the GET parm "mod" decides which module to trigger? |
20:47:18 | newb | Yes |
20:47:31 | Loge | what if someone spoof the parm with rubbish? |
20:47:36 | newb | Loge: i could be good to decide for query vars |
20:47:54 | newb | Loge: we can do what we want |
20:48:03 | k-fish | Loge: if we do it right, he/hse just won't see anything useful... |
20:48:06 | newb | Loge: warning screen or default one |
20:48:07 | Loge | newb:of course... thats a detail ... |
20:48:23 | newb | Loge: yeap, details .... :) |
20:48:45 | k-fish | Loge: this is a problem with all dynamic content. let's discuss this later :-) |
20:48:46 | Loge | lets talk about app class |
20:48:56 | k-fish | i have it on the screen... |
20:49:15 | newb | Loge: yeap, the var reg_mod tells if we register all module object one time |
20:49:26 | newb | or if we instantiate modules on demanfd |
20:49:49 | k-fish | newb: how do you keep the modules in the session? serialized classes? |
20:50:08 | newb | You just register the app object |
20:50:28 | newb | All object stored in the app object are saved with the app |
20:50:46 | Loge | newb: of course only values no skelletons :) |
20:50:55 | k-fish | ok. i found the relevant source lines, i guess. |
20:50:59 | newb | but the drawback is that all definition classes must be declared before, hence the first loop in index2.php |
20:51:16 | Loge | where is a loop? |
20:51:21 | newb | Loge: yes only values, hence the declaration stuff |
20:51:33 | k-fish | Loge: setModules() has two loops. |
20:51:56 | mdelamere | how do you nkow if a module is aktive or not, hence loading only aktive modlues into the session? |
20:51:58 | Loge | where is it called? |
20:52:00 | newb | No the loops of index2.php for including all classes definitions |
20:52:08 | Loge | ok |
20:52:25 | k-fish | newb: what about __sleep and __wakeup? |
20:52:25 | newb | It's just in case we decide to keep module objects in the app |
20:52:43 | k-fish | couldn't that save the problem? |
20:52:51 | Loge | mdelamere: what do you mean with active? |
20:52:56 | newb | k-fish: doesn't aware of this features.. |
20:53:11 | mdelamere | I thought you can deactivate modules (or not install them)... |
20:53:21 | mdelamere | the app has to knwo... |
20:53:23 | Loge | md: ah yes... newb whats with that? |
20:53:37 | Loge | right now you include everthing you find |
20:54:06 | newb | Loge: yes, we must think of the md point |
20:54:08 | k-fish | should be read from the db? or wherever the modulemanager stores it's data, no? |
20:54:19 | Loge | mgw_modules has a list |
20:54:36 | newb | k-fish: no, because |
20:54:45 | mdelamere | xml-descriptor in the modlues dir? |
20:54:48 | newb | this loop must be done before session |
20:55:05 | Loge | before session no db access?` |
20:55:15 | k-fish | newb: ah, i see. the __wakeup thing won't help here. but keep in mind. |
20:55:31 | newb | Loge: yes, but db stuff is managed by the app who is stored in session |
20:55:36 | Loge | voila XML |
20:55:51 | k-fish | :) |
20:55:58 | newb | :) |
20:56:03 | * k-fish wants more arguments... :-) |
20:56:04 | Loge | we really need to find active modules before |
20:56:15 | Loge | however we do this |
20:56:17 | newb | k-fish: what __wakeup and __sleep things ? |
20:56:52 | Loge | md: the module xml files wont help, cause they dont have activity infos |
20:57:16 | k-fish | newb: look at the php manual, chapter 13, classes and object. the parts about object serialization. |
20:57:22 | newb | what if we keep including all the module classes definition for the moment |
20:57:43 | Loge | newb: overload... |
20:57:48 | mdelamere | loge: ok |
20:58:11 | Loge | newb: and we need to know if its active .. cause then you cant call it :) |
20:58:11 | newb | newb: we can do without pre-including althought |
20:58:16 | Loge | and the menu writing and and and |
20:58:22 | mdelamere | why not in the db then?` |
20:58:37 | newb | Loge: you'r not in |
20:59:12 | Loge | ? confused |
20:59:22 | newb | Loge: after including all module cdefinition classes, we retreive the app object from session and the app is aware of active module |
20:59:23 | k-fish | do we absolutely need to load the module class files in index2.php |
20:59:43 | * k-fish asked a stupid question... |
20:59:45 | newb | k-fish: no, we can do without including all definition classes but |
21:00:02 | newb | so, we cannot store the modules in the app object |
21:00:08 | mdelamere | aware of active module? how? from where? |
21:00:12 | k-fish | newb: we need the class structure for deserializing the main app object. |
21:00:17 | newb | but we can load them on demand |
21:00:25 | Loge | ok lets put them in all, and the object know who is active (i hope) |
21:00:50 | mdelamere | Iīm losing you guys... |
21:00:56 | newb | Loge: in the actual db, there are info on active module, no ? |
21:01:15 | Loge | newb: mgw_modules |
21:01:21 | Loge | only active ones are in there |
21:01:38 | newb | So we the app object can know what module is active... |
21:01:41 | Loge | but thats of course beta |
21:01:48 | Loge | yeah theoretically |
21:02:12 | newb | Let's add a lcommented line in the init of the app if you want.. :) |
21:02:44 | mdelamere | why not create a mechanism whereby on startup, the system checks if a new folder exists in the modules folder and compare it to mgw_modules.... if a new one is found an entry is made into the db and the user is asked if he wants to activate it... |
21:02:44 | Loge | we log this session :) |
21:03:12 | newb | sorry |
21:03:16 | mdelamere | thereby we keep the automatic mechanism of adding modules |
21:03:16 | Loge | md: asking each time? |
21:03:23 | mdelamere | ? |
21:03:28 | mdelamere | on startup |
21:03:37 | Loge | md: what is startup?` |
21:03:37 | newb | Stop, let's go further in the concept |
21:03:46 | k-fish | Loge: once per session. save a flag in the session. |
21:03:59 | k-fish | newb: ok, summary anone? |
21:04:02 | Loge | oh no no .. this is the wrong way... |
21:04:15 | Loge | summarize: |
21:04:16 | mdelamere | why? |
21:05:11 | Loge | 1. index2.php and app classes are good from concept point |
21:05:11 | newb | we need an object who deal with the module object, right ? |
21:05:11 | newb | Loge: yes for 1 |
21:05:26 | k-fish | yep |
21:05:27 | Loge | 2. we have to discuss later if we want to load all module definitions or just active ones |
21:05:39 | k-fish | and how to do it... |
21:05:46 | Loge | 2b: we can leave it like it is now |
21:05:48 | mdelamere | I donīt see the poing in loading all |
21:05:52 | mdelamere | point |
21:05:53 | Loge | 2c: thos wont kill us |
21:05:55 | newb | all: the load all or on demand is already implemented |
21:06:08 | Loge | newb: i mean the active module load |
21:06:14 | mdelamere | whatīs the benifit of loading all |
21:06:14 | Loge | newb; this is not implemented yet |
21:06:34 | Loge | md: there is no, we know that this point is open.... |
21:06:42 | mdelamere | ok |
21:06:46 | newb | md: the benefit of loading all is : |
21:06:48 | Loge | md: but you know, we have some other areas to discuss :) |
21:06:57 | mdelamere | yes... |
21:07:07 | mdelamere | loge: are you trying to tell me something ;-) |
21:07:12 | newb | The overview feature can be implemented without touching a line of the overview module |
21:07:27 | Loge | newb: stop... |
21:07:30 | newb | The settings feature can be implemented without touching a line of the settings module |
21:07:34 | Loge | newb: taht was not the point |
21:08:07 | Loge | newb: or i didnt get your point |
21:08:18 | Loge | lets take an example |
21:08:26 | k-fish | newb: good points for loading all. |
21:08:28 | Loge | i dont need projects |
21:08:36 | Loge | so i wont isntall ot |
21:08:36 | newb | I'll provide : |
21:08:37 | Loge | it |
21:08:46 | Loge | then there is perhaps no need to load the classes or? |
21:09:09 | newb | http://www.lists.morelogs.de/pipermail/moregroupware-dev/2002-March/001370.html |
21:09:19 | newb | see that ... |
21:09:21 | Loge | i cant read this all |
21:09:29 | newb | Loge: why |
21:09:57 | newb | The text above the class definition ? |
21:10:11 | Loge | newb: ok read it, but talk about my real example |
21:10:24 | Loge | why including project.class when i dont have projects installed |
21:10:25 | k-fish | newb's link is about impementing overview and settings using his approach. |
21:10:43 | k-fish | Loge: no need to, indeed. |
21:10:45 | Loge | then you are one step too far |
21:11:09 | Loge | md and i talked about including classes when they are inactive / not installed |
21:11:19 | * k-fish knows... |
21:11:24 | newb | Are you aware of the benefit of loading all ? |
21:11:44 | Loge | no, so please tell me the benefit or having an included projects class |
21:11:47 | newb | Loge: this can be worked around |
21:11:53 | k-fish | newb: Loge is right, you don't need the benefit for modules you are not going to use anyway... |
21:12:16 | Loge | kfish: if wen can agree on this, we can proceed |
21:12:31 | mdelamere | I remember about a discussing including dependencies.... thatīs where it might make sense... the forum module for exmaple... if the guy doesnīt want it thereīs nothing else it has to offer to other modules :.-) |
21:12:39 | newb | All: we can only load classes that are needed |
21:12:42 | Loge | for the IRC LOG: we dont wanna include classes we dont need ... |
21:12:53 | k-fish | :-) logged! |
21:13:02 | k-fish | let's move on. |
21:13:02 | Loge | ok, settings is an interessting topic |
21:13:05 | Loge | cause its hot |
21:13:18 | k-fish | tell us about your new approach... |
21:13:27 | k-fish | how easy will this be? |
21:13:39 | Loge | md: dependencies is also an issue later on! |
21:13:52 | mdelamere | ok |
21:13:58 | newb | To summarize: we can have cool feature if we include all on startup or we can do with load on demand |
21:14:22 | Loge | or load all active :) |
21:14:22 | newb | anybody agree ? |
21:14:32 | k-fish | i have _contacts/settings/index.php in front of me. guided tour please :-) |
21:14:37 | newb | Loge: there's only two point here |
21:14:40 | k-fish | newb: yes. details later |
21:14:43 | Loge | kfish: tahts old |
21:15:03 | Loge | newb has a better variant |
21:15:04 | mdelamere | I think that each module however should define wether itz is to be included in the _ALL_ or not because it makes no sense to include the forum if it is inactive |
21:15:24 | k-fish | newb: ok, tell me... |
21:15:31 | Loge | md: we allready discussed that...IMO |
21:15:41 | k-fish | Loge: didn't you announce it only days ago? |
21:15:54 | Loge | kfish: yeah but its not OO oriented |
21:16:01 | k-fish | Loge: ok. |
21:16:04 | newb | md - loge: we can go with load on demand an then include only active module on demand, right |
21:16:20 | newb | md - loge: let's see load all on startup another time |
21:16:24 | Loge | newb: i think we all agree |
21:17:06 | newb | Ok: so, in index2.php, we can see that we retreive the app object from session or we create it if not in session |
21:17:13 | Loge | newb: please dont take this discussion as criticism of your work... |
21:17:43 | newb | Loge: i don't take this as criticism and i need criticism... :) |
21:17:51 | Loge | ok index2 |
21:18:01 | Loge | sure |
21:18:16 | * k-fish thinks: let's critize newb more often. it makes him work faster :-) |
21:18:18 | newb | After that, app->processAction() |
21:18:20 | mdelamere | I think we could be more flexible, we could create 2 groups.... module-group-all and module-group-on-demand or something like that.... that way we have the best of both worlds, the group coud be defined in an xml file |
21:18:24 | mdelamere | JUST AN IDEA!! |
21:18:32 | mdelamere | thinking out loud :-) |
21:18:36 | k-fish | mdelamere: logged :-) |
21:18:54 | newb | Md: there's a switch when we create the app that tell if load on demand or load all :) |
21:18:57 | k-fish | newb: processAction more or less only calls action on the active mod, right? |
21:19:09 | newb | Right |
21:19:24 | Loge | after constructor execution |
21:19:25 | k-fish | what if mod==NULL? any plans for that? |
21:19:26 | --> AW (~AW@morelogs3.e.revmap.vianetworks.de) has joined #moregroupware |
21:19:34 | AW | Hi Is anyone here? |
21:19:41 | mdelamere | how can mod be null? |
21:19:45 | newb | k-fish: error screen or default one (overview) |
21:19:47 | Loge | AW: dev talk, please no questions now |
21:20:05 | k-fish | mdelamere: if the get parameter for the mod to excute is not set... |
21:20:09 | Loge | md: good question |
21:20:12 | newb | Let's see mgw_app_class, ok ? |
21:20:14 | AW | awwww :) |
21:20:15 | Loge | kfish: oh :) |
21:20:16 | newb | Details later |
21:20:31 | Loge | ok |
21:20:35 | * k-fish says: use the source... |
21:20:43 | k-fish | ok |
21:20:44 | newb | So in mgw_app_class, we should find all the app stuff contained in the contained.inc |
21:20:52 | k-fish | right. |
21:21:06 | Loge | cant believe :) its too small :) |
21:21:15 | k-fish | newb: container.inc, you mean... |
21:21:18 | newb | It Loge: it's not finished |
21:21:30 | Loge | we need some more object wrappers |
21:21:40 | k-fish | Loge: the stuff from container.inc still has to go in there... |
21:21:43 | Loge | like tpl |
21:21:46 | Loge | ok |
21:21:50 | newb | I have put a db object, a tpl object and a user object |
21:22:07 | k-fish | (see app class constructor) |
21:22:07 | Loge | we would enahnce this step by step |
21:22:29 | newb | db object more or less operational |
21:22:29 | k-fish | lets walk through container.inc real quick to see what we need. ok? |
21:22:41 | Loge | all: but again we will have the following point, what to do with classes like encryption which we need not very often |
21:22:43 | newb | k-fish: i've done that |
21:23:22 | Loge | a switch/flag for including in mgw_app would be good |
21:23:22 | newb | Let's talk about this 3 object, ok, ? |
21:23:37 | newb | Loge: ? |
21:23:38 | k-fish | Loge: ??? |
21:23:46 | Loge | newb: these 3 are easy we need them allways |
21:23:49 | newb | Loge: i see, on load on demand ? |
21:24:02 | Loge | newb: ok we need a flag mechanism |
21:24:13 | newb | Loge: why ? |
21:24:34 | k-fish | Loge: if a certain object is needed, do if_class_exists, load if not. easy. |
21:24:35 | Loge | newb: i dont wanna have an object wrapper for encryption when i dont use it |
21:24:48 | Loge | kfish: no its not that easy |
21:24:52 | k-fish | should work, no? |
21:24:57 | newb | Guys, see getModule() |
21:24:58 | k-fish | why? |
21:25:02 | Loge | short stop |
21:25:10 | Loge | we have 3 object wrappers here |
21:25:13 | Loge | thats fine |
21:25:20 | Loge | but when we put some more there... |
21:25:29 | newb | k-fish; it's already done |
21:25:35 | Loge | i dont want instantiate them cause i dont need them all |
21:25:39 | | -- AW has quit (Remote closed the connection) |
21:25:58 | newb | Loge: this 3 abstraction module can be implemented incrementaly |
21:26:22 | newb | notes is operational without that |
21:26:26 | Loge | yeah, for instance: i dont need smarty...but it will be instantiated allways |
21:26:44 | newb | When a class is ready, we can switch step by step all module... |
21:26:59 | k-fish | it will be in the session anyway. and you will need it mostly, right? |
21:27:01 | newb | Loge: only one time, at the creation |
21:27:15 | Loge | newb: you didnt get me |
21:27:19 | newb | All: smarty is required |
21:27:27 | Loge | of course we need smarty! but that was an example |
21:27:41 | Loge | we we define encryaption class, we dont need it often |
21:28:08 | k-fish | see getModule()... |
21:28:17 | k-fish | seems reasonable. |
21:28:22 | newb | Loge: DB is an abstraction of the storage, always needed, TPL is an abstraction of the template/display mechanism, always needed, USER shoudl manage the rights |
21:28:25 | Loge | encryption is not a module its a library |
21:28:27 | newb | always needed |
21:28:41 | newb | Loge: let's see details as encryption later |
21:28:42 | Loge | newb: ok waht with classes not each time needed? |
21:28:55 | k-fish | Loge: so include it only when needed. let the module developer decide. |
21:29:00 | newb | The 3 objects are always needed |
21:29:00 | Loge | ok |
21:29:07 | Loge | newb: i know! grrrr |
21:29:12 | mdelamere | what one you could do is have get module(encryption) and dropModule(encryption) (a bit like the garbage collector in java) so that objects which arenīt used often are killed after use... |
21:29:21 | newb | So let's see that object only now |
21:29:39 | mdelamere | just a thought... |
21:29:41 | newb | They aren't needed in a first step |
21:29:49 | Loge | ok anyway |
21:29:51 | newb | as notes demonstrate it |
21:29:59 | Loge | so the module developer decides |
21:30:32 | Loge | i will come back to that point ... i have a better version for this |
21:30:33 | newb | I think when this 3 object are ready we won't need the container.inc anymore |
21:30:45 | Loge | lang class? |
21:31:08 | newb | Loge: language should be dealed by TPL |
21:31:17 | k-fish | newb: how? |
21:31:20 | Loge | newb: allready there? |
21:31:31 | newb | not already there |
21:31:35 | k-fish | Loge: no, see notes with index2... :-) |
21:31:53 | newb | but i think the module should not care a lot about language |
21:32:17 | newb | But we talk about that later |
21:32:45 | k-fish | ok. summary? |
21:33:17 | Loge | we summarized that we use object wrappers instead of container |
21:33:35 | newb | SUMMARY: the app class should manage the modules. The app_class should provide all features of container.inc: |
21:34:02 | newb | DB mechanisme, TPL template mechanism, USER, right management |
21:34:21 | newb | OK ? |
21:34:25 | k-fish | and more if needed later... sounds good! |
21:34:29 | Loge | so far so good |
21:34:37 | k-fish | what next? |
21:34:41 | Loge | settings |
21:34:48 | k-fish | ok. newb your proposal? |
21:34:56 | k-fish | (heard you have a good one...) |
21:35:04 | newb | I want to talk about module output |
21:35:19 | Loge | ok |
21:35:24 | k-fish | ok, wanted to ask about that anyway. |
21:35:28 | Loge | should be a quick one or? |
21:35:35 | k-fish | you had the module return something. is that gone? |
21:35:42 | k-fish | or still there? |
21:36:34 | newb | k-fish: i think that module->action() should return a template and an array of data to be binded by smarty |
21:36:42 | newb | What about you |
21:37:06 | k-fish | but then it could display it directly,no? |
21:37:11 | newb | I think it's up to the app to rander all but the little frame of the module |
21:37:27 | k-fish | on the other hand, you could have some output plugins this way... |
21:37:29 | Loge | yeah thats right with the rendering |
21:37:32 | k-fish | newb: ok |
21:37:54 | Loge | but this will be hard |
21:38:04 | k-fish | so the module's templates would contain only the module only stuff? right? |
21:38:17 | newb | I mean the module frame should be displayed by the TPL object but it's up to the module to provide the template and the data to bind |
21:38:19 | newb | ok ? |
21:38:30 | k-fish | sounds reasonable. |
21:38:39 | Loge | newb: yeah, templates are created this way |
21:38:47 | newb | Or we can pass the TPL object to the module and it's up to the module to render it |
21:38:48 | Loge | seperation allready exists (in templates) |
21:38:54 | newb | but it's more messy |
21:39:03 | k-fish | i like the idea... |
21:39:05 | Loge | its with include inside templates |
21:39:19 | newb | And if we want to change a thing in TPL, i don't want to change all modules code... :) |
21:39:30 | k-fish | good point. |
21:39:51 | newb | k-fish: i knew this point would please you ;) |
21:40:03 | Loge | its allready there ... so the same functionality |
21:40:19 | k-fish | this way the menubar, footer, everything not directly related to the module would be completely seperately |
21:40:28 | Loge | its also there |
21:40:31 | Loge | regarding templates |
21:40:35 | mdelamere | what about $content=$app->module->fetch($module_template); ---- $main->smarty->assign("content", $content); |
21:40:38 | k-fish | the mod developer wouldn't have to include the stuff in his tenplates... |
21:40:42 | mdelamere | or something similar! |
21:40:51 | newb | So mod->action() should return somthing like an array ['newnotes.tpl',note['id=tit,descrption=toto...] |
21:40:55 | Loge | kfish: yeah thats the point |
21:41:15 | Loge | new |
21:41:19 | Loge | newb: wow stop |
21:41:33 | Loge | you want to give back each parm??? |
21:41:50 | newb | yes |
21:41:53 | Loge | what with a listing of 20 rows with 10 cells |
21:42:05 | mdelamere | all: I suggested something ;-) |
21:42:06 | k-fish | newb: what about modules that return PDF,vcards,*whatever*? just output and exit()? |
21:42:13 | newb | No: the module do |
21:42:25 | Loge | md: its too fast here |
21:42:32 | Loge | we must do a loop |
21:42:33 | mdelamere | :-) |
21:42:40 | Loge | in conversation |
21:42:47 | mdelamere | what about $content=$app->module->fetch($module_template); ---- $main->smarty->assign("content", $content); |
21:42:48 | newb | instead of doing plenty of smarty->assign('foo','bar') |
21:42:49 | mdelamere | again :-) |
21:43:16 | newb | md ? |
21:43:20 | Loge | yeah why not returning blocks of html? |
21:43:37 | newb | only action can return a template and an array of data to bind, no ? |
21:43:50 | mdelamere | you can fetch templates and assign them to the main template |
21:44:02 | k-fish | newb: or html to put into the output... |
21:44:02 | mdelamere | smarty has itīs own fetch method... |
21:44:04 | newb | the modules currently do lot of assignment |
21:44:19 | Loge | newb: its not bad or? |
21:44:33 | k-fish | newb: yes, but the stuff can stay in the mods, no? and be streamlined there... |
21:44:48 | * k-fish thinks he's getting the point. slowly. |
21:44:59 | * newb is overloaded ... |
21:45:07 | Loge | this is a critical point.... |
21:45:18 | k-fish | newb: you want the modules to deal only with logic, and move the display out completely?!? |
21:45:21 | Loge | we can give back raw data.... |
21:45:23 | Loge | cant |
21:45:24 | newb | Yes, that's why i wanted to talk abtou that |
21:46:02 | newb | k-fish: yes, just let's module provide templates and data to bind and let's the TPL object deal with that |
21:46:06 | Loge | why not returning the half rendered template like md suggested? |
21:46:34 | mdelamere | or one could just send the smarty reference into the module object which then assigns or appends the data.... display will be carried out by the main app object....? |
21:46:55 | mdelamere | loge: I like that idea... |
21:47:11 | newb | Stop: what about each one write his thoughts and publish it ? |
21:47:27 | Loge | newb: yeah its too critical otherwis |
21:47:27 | Loge | e |
21:47:37 | k-fish | and then meet again in a few days to discuss it? ok with me... |
21:47:47 | mdelamere | fine by me... |
21:47:48 | Loge | ok |
21:47:54 | newb | i don't want module to deal with any template object because if a changement occurs, i don't want to modify each module... |
21:48:18 | Loge | what template object you mean? |
21:48:19 | newb | The nicer is that a module output just a template and the values of the data to bind, simple isn't it ?? |
21:48:33 | mdelamere | well I donīt see how the main app is going to be able to do the assigning of every module# |
21:48:39 | Loge | newb: i dont be conform with your idea . i must admint |
21:48:41 | Loge | admit |
21:49:06 | Loge | but lets do the real world examples later on...then we meet again |
21:49:24 | k-fish | (can't smarty assign an associatvie array to a template? that would work.) |
21:49:31 | Loge | stop stop stop := |
21:49:33 | Loge | :) |
21:49:36 | k-fish | ok :-) |
21:49:48 | newb | All: see the actual classes and let's criticism it and propose ... |
21:49:52 | Loge | lets do the general discussion today and split things up |
21:50:00 | mdelamere | ok |
21:50:01 | Loge | we cant do it all today |
21:50:11 | newb | k-fish, yes sure, smarty can assign an array of value |
21:50:18 | Loge | newb: ARGH |
21:50:25 | k-fish | summary: md and newb try to write down some stuff on displaying, we meet again to discuss it. ok? |
21:50:32 | newb | sorry but k-fish seems to understand me... :) |
21:50:37 | Loge | kfish: i will also try to show something :) |
21:50:41 | mdelamere | no problem :-) |
21:50:44 | k-fish | (id, we can work on it together...) |
21:50:52 | Loge | (some right for the inventor?) :) |
21:50:56 | k-fish | (i do...) |
21:50:59 | k-fish | Loge: No :-) |
21:51:09 | * k-fish is just kidding again |
21:51:17 | k-fish | what next? |
21:51:36 | k-fish | (why doesn't the bot have some good ideas?) |
21:51:37 | newb | wher's rabol ? |
21:51:41 | Loge | thats harder than working here |
21:51:48 | Loge | newb: dont know |
21:52:06 | k-fish | probably fell asleep :-) |
21:52:15 | newb | Ok, let's go to some idea obout module architecture now ? |
21:52:22 | k-fish | ok |
21:52:34 | Loge | right now we have only switch and functions |
21:52:47 | Loge | inside action() |
21:52:51 | newb | I propose some kind of standard query string vars: |
21:52:57 | k-fish | should be methods. called by action(). |
21:53:10 | newb | mod=notes&obj=group&view=neform |
21:53:23 | k-fish | ok, obj instead of part. ok |
21:53:32 | k-fish | why view, not action? |
21:53:37 | newb | Can we look at notes.class.php ? |
21:53:38 | Loge | what is obj? |
21:53:48 | k-fish | or is action something like save, delete? |
21:53:54 | Loge | yeah |
21:53:58 | newb | k-fish because newfrom is the template to display, the view to offer |
21:54:00 | k-fish | newb: have it on the screen... |
21:54:05 | k-fish | newb: ok. |
21:54:23 | k-fish | (this actually works :-)) |
21:54:39 | k-fish | try: index2.php?PHPSESSID=bc9fd9e76efcaadf8f0be0e868547482&mod=notes&part=groups&view=newform |
21:54:43 | newb | All: are you ok about that ? |
21:54:59 | k-fish | what about action? the way i wrote? |
21:55:00 | newb | k-fish; sure it works |
21:55:04 | k-fish | :-) |
21:55:12 | Loge | i like action i need action! |
21:55:14 | mdelamere | thereīs somehting I donīt like: I donīt think that any html tags should be written directly in php-scripts |
21:55:24 | Loge | i made several changes just because of this |
21:55:25 | mdelamere | only in templates |
21:55:28 | k-fish | mdelamere: where? |
21:55:29 | newb | md: i agree |
21:55:40 | mdelamere | img and href |
21:56:10 | Loge | can we end the get discussion? |
21:56:17 | newb | Yes |
21:56:23 | Loge | i want to have action |
21:56:23 | k-fish | ah the symbol stuff. should go somewhere central anyway! |
21:56:27 | Loge | its implemented everywhere |
21:56:37 | newb | Loge: why |
21:56:43 | k-fish | and always the same. should be moved... |
21:56:52 | newb | action mean about eveything in mgw |
21:56:52 | Loge | why not? |
21:56:58 | Loge | what else? |
21:57:20 | Loge | for me action is unique |
21:57:28 | newb | action means the template to display and the action with the db (update, delete...) |
21:57:42 | Loge | the temaplte to display? |
21:57:50 | k-fish | view means the template, action the action |
21:57:53 | newb | I would propose mod,obj,view,op |
21:58:07 | Loge | newb: recoding all modules? |
21:58:09 | newb | op could mean the operation on db |
21:58:25 | k-fish | Loge: we will anyway. slowly but steadily... |
21:58:28 | newb | Loge: just variable substitution |
21:58:41 | k-fish | and have it clean afterwads. +1 |
21:58:55 | Loge | i see getparm stuff there! |
21:58:58 | mdelamere | action and op?? |
21:59:02 | newb | There's currently no guidlines, and we must have one |
21:59:16 | k-fish | op instead of action. right? |
21:59:20 | mdelamere | ok |
21:59:25 | k-fish | i think the getparm stuff is old... |
21:59:37 | newb | No: mod=notes&obj=group&view=list&op=delete&id=3 |
22:00:03 | k-fish | ok |
22:00:06 | Loge | newb: ok, bye bye action (loge wait for next compromise on newb side) |
22:00:10 | mdelamere | what is obj for again? |
22:00:13 | mdelamere | again |
22:00:16 | newb | means module=notes the object is group i want to view the list of groups and i want to delete the group 3 |
22:00:34 | k-fish | in opposite to deleting a note :-) |
22:00:47 | k-fish | mdelamere: got it? |
22:01:04 | newb | Loge: let's replace op by action to please the boss ... :) |
22:01:16 | mdelamere | no.. I donīt understand, what group? |
22:01:20 | Loge | newb: no no, lets go |
22:01:23 | newb | I like short var name in query strings |
22:01:24 | mdelamere | notes group or what? |
22:01:33 | k-fish | yes |
22:01:44 | Loge | i think we will use 99% view=list or? |
22:01:51 | newb | Loge: yes |
22:01:53 | Loge | do we need it really? |
22:01:56 | newb | Loge: 60% |
22:02:17 | Loge | but ok, makes no damage |
22:02:26 | k-fish | view could be used for different sorting oders (something i miss now)... |
22:02:30 | newb | it's cleaner to have all the var with data |
22:02:35 | Loge | the interessting point would be to jump to a screen of a differetn module |
22:03:28 | newb | Loge: no prolem, point to mod=contact&obj=entreprise&view=list |
22:03:55 | Loge | newb: no i mean after deletion of module_b item |
22:03:58 | newb | or point to mod=contact&obj=contact&view=list&action/op=delete&id=2 |
22:04:14 | Loge | mod=notes&obj=group&view=contact_list&op=delete&id=3 |
22:04:41 | mdelamere | what if these parameters are still in the session and whilste changing the module mod=forum (in session &op=delete&id=3) oops we have just deleted a forum maybe :-) |
22:04:41 | newb | Loge: no because the op and view depend on obj |
22:04:54 | Loge | ok |
22:05:07 | newb | md: confirmation screen |
22:05:16 | mdelamere | ok |
22:05:23 | Loge | so next? |
22:05:25 | newb | I have proposed to Loge to put op/action vars in POST |
22:05:37 | Loge | LOG: i dont like getparm |
22:05:38 | newb | Can we agree an that ? |
22:05:51 | newb | what is getparm |
22:05:59 | Loge | newb: i started it allreafy with hidden fields |
22:05:59 | newb | The rabol helper functions ? |
22:06:04 | Loge | yeah |
22:06:15 | Loge | i would like to work with $_Ü |
22:06:15 | Loge | * |
22:06:18 | newb | I don't like it too much too |
22:06:31 | k-fish | Loge: rabol said he would remove them again... |
22:06:51 | k-fish | Loge: was discussed on the mailing list on March 5th |
22:06:58 | Loge | all: so we agree on op hidden post vars!?! |
22:06:58 | newb | I don't think $_POST $_GET and so would be changed tomorrow |
22:07:03 | k-fish | rabol: did you hear me :-) |
22:07:07 | Loge | newb: they are just introduced :) |
22:07:19 | mdelamere | I personally think that the $_ should be registered with the objects and called with either $this->getparm() or $this->variable (i.e. avoiding globals) |
22:07:34 | Loge | md: this is not a global |
22:07:36 | k-fish | mdelamere: they are superglobal anyway. no need to register them... |
22:07:36 | newb | Loge: i means that we have to chang the general confirmation screen for deletion to pass the op in a hidden filed |
22:07:52 | Loge | newb: we have to cahnge each edit/new form |
22:08:13 | Loge | newb: but its ok... |
22:08:25 | Loge | newb: no other way if you wnna do it clean |
22:08:41 | newb | md: i think i can see what you tell |
22:08:44 | newb | :) |
22:08:59 | mdelamere | hmm.. I donīt quite agree with using $_* in objects.... I think it starts to become confusing |
22:09:05 | newb | md: you would pass paramater in mod->action($_GET['mod']....) |
22:09:06 | Loge | why? |
22:09:26 | mdelamere | well, the complete array... |
22:09:31 | newb | md: you would pass paramater in mod->action($_GET['obj']....) |
22:09:44 | Loge | what array? |
22:09:52 | newb | md: sure mod->action($_GET] |
22:10:01 | Loge | hmmm |
22:10:07 | Loge | and then in the module? |
22:10:28 | mdelamere | 1) for readabilty and 2) what if they change the vars again... in the forum I use $this->vars which means that I only have to change one line to switch from HTTP_* to $_* .... :-) |
22:10:28 | Loge | explode? |
22:10:43 | k-fish | newb: this is superflous. the $_GET would be accessible anyway! |
22:10:48 | Loge | i dont like it ,, i want to have control over post and get |
22:11:07 | Loge | dont mix them in one array |
22:11:45 | newb | Loge: agree but instead of dealing with $_POST and $_GET array inside the action function |
22:11:48 | Loge | so where is the drawback? if they change again, we have to do searvch/replace anyway |
22:12:06 | mdelamere | on I just have to change one line |
22:12:08 | mdelamere | no |
22:12:16 | Loge | one line? where? |
22:12:31 | newb | why don't we declare vars used in the function function action($mod,$obj,$view,$op...) |
22:12:41 | newb | md: that's it ?? |
22:13:01 | Loge | stop |
22:13:05 | mdelamere | at the moment I have $forum->action($vars); |
22:13:16 | k-fish | newb: you will never know, what the next funky module will need... |
22:13:25 | newb | Loge: ok, we can discuss that furether |
22:13:25 | Loge | what is $vars? |
22:13:36 | k-fish | we should stick with $_GET and $_POST. they are clean, IMHO |
22:13:49 | mdelamere | $vars = array_merge($HTTP_POST_VARS, $HTTP_GET_VARS); |
22:13:52 | Loge | NO! |
22:13:58 | mdelamere | I know... :-) |
22:14:03 | newb | k-fish: ok, let's do |
22:14:05 | k-fish | mdelamere: not clean. besides there is $_REUQEST for that. |
22:14:12 | newb | md: crappy :) |
22:14:15 | Loge | no way ... mixing vars ... we allready have this in actial 0.6 version |
22:14:16 | mdelamere | lol |
22:14:18 | mdelamere | thx |
22:14:40 | mdelamere | but that wasnīt oo which meant that it was all mixed up anyway :-) |
22:14:47 | Loge | so where is the drawback of $_* inside modules? |
22:14:57 | k-fish | i see none... |
22:15:04 | newb | Ok, so what are the standard vars ? mod,obj,view and op, action ? |
22:15:27 | Loge | yeah why? |
22:15:36 | k-fish | yes, i'd say that is the common basic subset. agreed. |
22:15:38 | newb | op or action should be passed by post |
22:15:47 | Loge | op! |
22:15:48 | Loge | :) |
22:15:52 | k-fish | op! |
22:15:59 | newb | new: op! |
22:16:04 | Loge | not only op what is with the others? |
22:16:22 | Loge | i dont like <form action="bla.php?var=sdsd"> |
22:16:33 | k-fish | could be get. op should be post, it will be a button most of the time anyway. |
22:16:37 | k-fish | Loge: right. |
22:16:46 | newb | mod to indicate the module, obj to indicate the object (contact entreprise, user,group...) |
22:17:04 | k-fish | but what about lists? the icons are just links, only get there.... |
22:17:09 | Loge | yeah but how the others should be in the forms? get or post? |
22:17:20 | Loge | lists are allways get thats a matter of fact |
22:17:27 | k-fish | in a form, everything is post, if the form is post! no? |
22:17:33 | newb | op are update, delete, and create only |
22:17:37 | Loge | kfish: correct! |
22:17:57 | Loge | so no mix up with get and post in forms |
22:18:11 | k-fish | newb: what about copy and move? will we need that somewhere? just thinking... |
22:18:19 | k-fish | Loge: right. |
22:18:34 | newb | k-fish: copy and move ? |
22:18:35 | Loge | newb: ok about op |
22:19:04 | Loge | md: are u still with us or was the $_* disucssion too heavy :) |
22:19:05 | k-fish | k-fish: yes, e.g. copy one contact, and just fix the name and phone, if everything else is identical |
22:19:22 | * k-fish is talking to himself... oh no:-) |
22:19:28 | mdelamere | no I still donīt agree but that is democracy :-) |
22:19:28 | k-fish | i meant newb: |
22:19:32 | newb | on a list: view=details or view=newform (to update) or view=deleteconfirmation |
22:19:51 | newb | and on the delete confirmation form, we post the op=delete |
22:19:57 | k-fish | newb: right. |
22:20:08 | newb | Logic, the delete confirmation is a view, no ? |
22:20:17 | Loge | btw confirmation screen and post was a problem until now |
22:20:17 | k-fish | newb: yes. |
22:20:20 | Loge | must be solved |
22:20:35 | newb | Loge: solved, no ? |
22:20:42 | Loge | must be solved |
22:20:43 | mdelamere | anyway Iīm also waching uefa cup :-) |
22:20:51 | k-fish | bah, soccer :-) |
22:20:59 | mdelamere | yep ;-) |
22:21:14 | newb | rugby rules ;) j |
22:21:18 | Loge | newb: can you document the states of vars? |
22:21:19 | newb | just kidding |
22:21:37 | Loge | i mean the possible vals |
22:21:44 | Loge | with op for instance |
22:21:45 | newb | Loge: it was a problem on delete when on a list view |
22:22:16 | newb | but the problem is resolved by view=deleteconf get string |
22:22:24 | Loge | ok lets see |
22:22:28 | Loge | whats next? |
22:22:42 | newb | And the confirmation screen put THEN a op=delete in POST |
22:22:48 | k-fish | summary: newb documents variables :-) |
22:22:56 | newb | So that op is always in post |
22:23:05 | Loge | newb: we must try yes |
22:23:14 | newb | So that messing with the query string isn't dangezrous for the data |
22:23:40 | newb | By the way, can we see the notes.class.php ? |
22:23:49 | Loge | i allready stearing at it |
22:24:18 | newb | Cool, have you see the distinct part in the switch |
22:24:29 | newb | the data handling functions and the view handling ones ? |
22:24:34 | Loge | disctinct? |
22:24:43 | Loge | ok |
22:24:44 | Loge | yeag |
22:24:47 | newb | The data handling functions can be called by others module |
22:24:51 | newb | view one not |
22:25:00 | k-fish | yes, i do not get the way the data is handed over to the data handling functions... |
22:25:13 | Loge | little bit hard to read |
22:25:28 | newb | k-fish: sorry it's still the mess, don't have finished |
22:25:37 | k-fish | newb: ok. |
22:25:48 | k-fish | newb: any ideas on how to do this? |
22:25:51 | Loge | i wont imagine how module would look like with 4 main scripts |
22:26:10 | newb | But i wanted to make the distinctiopn between functions that deal with data (op=delete,op=create,op=update) |
22:26:58 | newb | that can be called by other modules (and that could migrate into a single object (note,group,contact entreprise (that's another story)) |
22:27:21 | Loge | cant follow |
22:27:32 | k-fish | newb: i see what you aim at. nice. |
22:27:42 | Loge | why do you have smarty in create function? |
22:27:51 | newb | Another module should do this->getModule('notes')->deleteGroups(id) |
22:28:11 | newb | Loge: because the TPL object is not ready ;) |
22:28:13 | k-fish | Loge: backwards compatibility |
22:28:22 | newb | Yes |
22:28:30 | Loge | we should pass $smarty and $conn |
22:28:34 | Loge | not global |
22:28:53 | k-fish | Loge: they will be part of the (app) object later... |
22:29:02 | newb | Loge: yes, but after we just have to do $this->tpl or $this->db |
22:29:09 | Loge | kfish: i see of course :) |
22:29:17 | Loge | i am old |
22:29:31 | k-fish | hehe :-) don't worry.... |
22:29:45 | newb | Perhaps that k-fish and i should continue to encapsulate and we could talk again later ? |
22:29:55 | Loge | this is a great idea |
22:30:09 | Loge | i am a little bit out of power i must admit |
22:30:11 | newb | But do you guys see where we want to go |
22:30:20 | k-fish | i hope so... |
22:30:33 | * newb should do a doc |
22:30:39 | k-fish | have the feeling of "yes, i seem to..." |
22:31:09 | newb | k-fish: you understand me at least |
22:31:09 | Loge | the direction is fine |
22:31:13 | newb | :) |
22:31:23 | k-fish | what is the timeframe for the next steps? will we dump the old index.php before 0.7 completely? |
22:31:24 | Loge | he we can manage also the cross module communication ... this would be great |
22:31:31 | Loge | yeah |
22:31:54 | Loge | 0.7.0 will take long i think...we must fine someone who pushes some more 0.6 releases for the crows |
22:31:57 | Loge | crows |
22:31:59 | mdelamere | Iīm missing the seperation between view and controler code in the notes object... how can another module just get an array of notes or something like that.... your list notes should be calling a gets notes function which gets the notes according to the givern parameters |
22:32:01 | Loge | crowd |
22:32:25 | k-fish | mdelamere: will come. newb mentioned that, if i understood correctly. |
22:32:28 | newb | md: notes is note finished |
22:32:28 | mdelamere | the listNotes() should then be doing the view stuff |
22:32:34 | mdelamere | ok |
22:32:49 | newb | md: a function that return an array of notes could be done |
22:32:53 | mdelamere | but we really should be carefuly of keeping controller code and view code seperate |
22:32:57 | Loge | guys lets speak about release management |
22:33:03 | k-fish | yes. yes. |
22:33:10 | newb | but in final, we could introduce the note object, but that's a step further |
22:33:17 | mdelamere | yes |
22:33:20 | * k-fish answered to questions in one line. wow! |
22:33:23 | Loge | we must release 0.6.3 soon |
22:33:43 | k-fish | yes, you asked about testing. any volunteers yet? |
22:34:05 | Loge | kfish: no :) i wanted to ask hondzik cause he does some commits in the 0.6 tree lately |
22:34:22 | Loge | kfish: if not i will test the actual CVS and do a release later next week |
22:34:42 | Loge | kfish: so lets make some tasks! |
22:34:48 | newb | Loge: may i have the permission to do a admin.class.php in module/admin ? |
22:34:50 | k-fish | i think at least the repaeting bugs (channels, ...) should be gone for 0.6.3. what about that? |
22:34:56 | k-fish | they are all assigned... |
22:34:57 | Loge | kfish+newb: 0.7 OO dev? |
22:35:16 | Loge | newb: yeah... |
22:35:17 | k-fish | and 0.6.x for the masses... |
22:35:32 | Loge | kfish: i need one more to test with the actual 0.6 CVS |
22:35:38 | Loge | with me |
22:36:00 | Loge | md: what are u doing besides TV? :) |
22:36:03 | k-fish | i have both trees set up here. i can do some testing. split it up? |
22:36:08 | newb | I won't be available until next week, monday or wednesday |
22:36:12 | mdelamere | talking to you guys :-) |
22:36:20 | newb | Then i'll have more time |
22:36:27 | mdelamere | Iībe given up with jboss for today ;-) |
22:36:29 | newb | :) |
22:36:33 | Loge | md: $_* migration? :) |
22:36:34 | k-fish | same with me, the weekend is busy. |
22:36:35 | mdelamere | Iīve |
22:36:41 | Loge | not today... the next days... |
22:36:50 | mdelamere | loge: will be done |
22:37:01 | Loge | i dont speak about deadlines... i cant stand them also :) |
22:37:20 | mdelamere | I will also do the smarty example |
22:37:28 | Loge | but i think today we made a good step |
22:37:29 | newb | k-fish: i don't see you too much on irc :( |
22:37:41 | Loge | its good to know the people know whats going on and what the direction is |
22:37:45 | k-fish | i had a lot of work last week. next week will be better. |
22:37:58 | newb | k-fish: cool |
22:38:10 | Loge | hondzik is committing niceley but very rare on IRC |
22:38:21 | newb | k-fish: i was lost in templates this week |
22:38:57 | Loge | BTW i am in hamburg from monday -> wednesday w/o internet (IBM course) |
22:38:57 | newb | k-fish: haven't a lot of time and was new to mgw templates/ smarty |
22:39:18 | k-fish | Loge: could you mail bregeras and ask him to close some of the headlines bugs? |
22:39:35 | Loge | kfish: yeah he is on a project far away from home i believe :) |
22:39:41 | newb | I'll have to go guys |
22:39:44 | Loge | newb: cu |
22:39:50 | k-fish | i will try to tackle some of the vcard stuff. |
22:39:57 | mdelamere | cu |
22:40:01 | k-fish | newb: get in touch next week. just drop me a mail... |
22:40:07 | newb | k-fish: ok |
22:40:12 | newb | cu guys |
22:40:12 | k-fish | bye newb.... sleep well! :-) |
22:40:16 | Loge | all: if someone meet stunti...please ask him chasing bugs. |
22:40:28 | | -- newb has quit ("good night") |
22:40:37 | Loge | kfish: so we should try to hunt some bugs and bring out 0.6.3? |
22:40:45 | Loge | and please double commit... |
22:40:57 | k-fish | 1. yes. 2. sure |
22:41:12 | Loge | since 0.6.2 i allready fixed some amount of bugs |
22:41:41 | Loge | i will switch to 0.6 CVS next days ... (when i am not on business tour) |
22:42:02 | k-fish | so it will be only bug fixing on 0.6.x. no new features. right? |
22:42:17 | Loge | md: you saw new developer page? |
22:42:26 | Loge | kfish: correct |
22:42:32 | mdelamere | not yet |
22:42:36 | Loge | perhaps very small ones :) |
22:42:37 | mdelamere | hang on.. |
22:42:55 | k-fish | maybe you should put up a new roadmap, something at least stating: don't file bugs on webmail, will be rewritten. or something like that. |
22:43:22 | mdelamere | my picture is going further and further down ;-) |
22:43:34 | Loge | kfish: yeah ... after all this OO framework things, we MUST !!!!! do enduser things |
22:43:39 | mdelamere | but looks good ;-) |
22:43:54 | Loge | md: i can place you higher if you want :) |
22:44:13 | mdelamere | I think that is in order! ;-)( |
22:44:15 | mdelamere | :) |
22:44:18 | k-fish | Loge: you asked me for a pic. will send you one next week. hopefully :-) |
22:44:18 | Loge | kfish: cause webmail and calendar are evil like hell and everybody knows that |
22:44:24 | Loge | kfish: ok |
22:44:28 | brr | Many good decisions taken this evening? |
22:44:35 | Loge | brr: i think so |
22:44:40 | k-fish | hi brr! thought you were asleep :-) |
22:44:57 | k-fish | we decided to dump the norwegian translation... |
22:44:59 | Loge | kfish: can you send me the log via email, i will publish it |
22:45:04 | Loge | hehe |
22:45:06 | k-fish | (just kdding, sorry) :-) |
22:45:07 | brr | No. I am here... But I have been watching TV and not followed the discussion. |
22:45:14 | brr | k-fish: VERY FUNNY! |
22:45:21 | k-fish | uefa cup? like mdelamere? |
22:45:31 | Loge | kfish: can you send me the log via email, i will publish it |
22:45:35 | brr | I am not interested in sports. |
22:45:35 | k-fish | brr: sorry :-) keep up the good work! |
22:45:51 | k-fish | Loge: will do. |
22:46:20 | k-fish | ok. anything else? or shall we stop? |
22:46:39 | Loge | kfish: lets stop... all things are targeted |
22:46:49 | Loge | kfish: you live in braunschweig? |
22:46:56 | k-fish | a last summary anyone? (yes, i do) |
22:46:58 | Loge | kfish; we should meet some time ... |
22:47:17 | k-fish | sure. let's wait until you owe me a beer for somthing :-) |
22:47:25 | Loge | kfish: for free :) |
22:47:35 | k-fish | summary: |
22:47:41 | k-fish | 1. oo is good |
22:47:47 | k-fish | 2. one index file is good. |
22:47:57 | k-fish | 3. display stuff still to be discussed |
22:48:17 | k-fish | 4. vars for op are post. newb documents the possible values. |
22:48:39 | k-fish | 5. bug fixing on 0.6.x, OO'ing on 0.7 CVS |
22:49:13 | k-fish | 6. object will be refined on the way to allow inter-object communication. |
22:49:33 | k-fish | 7. and a few tons of new stuff, bugfixing, recoding, ... |
22:49:50 | Loge | 8. after all this -> enduser focus |
22:49:52 | --> canani (~canani@cm-net-poa-C8B0C092.brdterra.com.br) has joined #moregroupware |
22:50:15 | k-fish | is that it? when the log is published, does anyone volunteer to write a more detailed summary? |
22:50:34 | Loge | kfish: i will write one, i can do this w/o internet on monday |
22:50:42 | k-fish | great! |
22:51:00 | Loge | canani: are you ready for some improvements? :) |
22:51:16 | k-fish | ok, if you want anything to be in the log, say it now, before i am gone (though i will stay some minutes, still)... |
22:51:22 | Loge | canani: i am still eager to solve all mysql related stuff inside SQLs |
22:51:57 | Loge | i even use $adodb->concat() functions |
22:52:18 | Loge | kfish: close it :) i will modify it anyway :) |
22:52:27 | Loge | kfish: in a way that i must do nothing :) |
22:53:24 | k-fish | i will double check and cry out loudly if you do :-) just don't do it ;) |
22:54:20 | Loge | i am excited what emailtom will do with his webmail app regarding mgw |
22:54:20 | canani | Loge: I'm working on 0.7 sqls right now |
22:54:30 | Loge | i cnat believe he will get it mgw compliant |
22:54:39 | Loge | canani: really? fine |
22:55:00 | Loge | i just saw another mysql thing (unix_timestamp) in project/index.php ... i will solve this |
22:55:36 | canani | i've posted an script for detecting Mysql specific code some weeks ago |
22:56:13 | canani | do you think it'd be useful to post the script's output runniog against 0.7 ? |
22:58:39 | k-fish | ok guys. i will leave now. Loge, you will have the log in your mail shortly. bye and thanks to all for the friendly and constructive discussion. up, up and away! |
22:58:45 | Loge | yeah and then post the ourput to the list |
22:58:55 | Loge | kfish: n8 |
22:59:18 | --- You have left channel #moregroupware ("good night...") |