phpwebapp-improvments Mailing List for phpWebApp
Brought to you by:
dashohoxha
Menu
▾
▴
phpwebapp-improvments — For discussing improvments that can be made to the framework.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(13) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 12:31:47
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: SourceForge.net <no...@so...> - 2003-08-05 14:30:58
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2136667 By: dashohoxha Before using a webobject it has to be included like this: <Include SRC="{{LISTBOX_PATH}}listbox.html" /> where 'listbox.html' contains the declaration of the <WebClass> listbox. Then we use it like this: <WebObject Class="listbox" Name="list1" . . . /> It would be better if the framework knows itself about the location of the standard webclasses and can include them automatically when an instance of this webclass is used. In such a case there would be no need for the first line above. In case that it is not a standard webclass (and the framework does not know about its location), or the developer wants to override a standard webclass, then it can tell to the framework about the path of the webclass using one of the following ways: 1 - <IncludeWebClass ID="my_listbox" PATH="path/to/my_listbox/" /> This is similar to the <Include> above, but has a more specific syntax and there is no need to use it for the standard (registered) webclasses. 2 - <WebObject Class="my_listbox" Path="path/to/listbox/" Name="list1" . . . /> In this case the location of the webclass is specified at the declaration of the webobject (/path/to/listbox/my_listbox.html is the file that will be used by the framework and it should contain the definition of the 'my_listbox' <WebClass>). 3 - WebApp::use_webclass("my_listbox", "path/to/listbox/"); This should be called in init() or in onParse() and it is like registering this webclass so that the framework knows how to find it. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-08-05 13:13:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2136546 By: dashohoxha Sometimes, small WebBox-es with a single line, like this: <WebBox ID="box_id"> <Include SRC="{{./}}{{file}}" /> </WebBox> are used to include a file according to some condition. Maybe it is better to use another more specific syntax, like this: <FileSwitch ID="switch_id" FILE="{{...}}" /> In this case, the file 'switch_id.php' will contain the PHP code that will actually decide which file is going to be included (according to the state of the application). It will be something like this: <?php class switch_id extends FileSwitch { function init() { . . . } function switch() { . . . } } ?> where FileSwitch extends WebObject (so it may have state variables) and the function switch() is called during the parse (similar to function onParse() of the WebObject). ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-08-05 12:40:44
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2136488 By: dashohoxha WebBoxes and Recordsets have IDs that must be unique in the whole application. This brings some difficulties for big applications or when including an external module (prepared by somebody else) because there is a chance that two weboxes (for example) have the same ID. Maybe this can be solved by requiring them to be unique only in the context (the scope) in which they are used. For example: ------------ webobj x | +--> webobj x1 | | | +--> webobj x2 | +--> webobj x2 | | | +--> webobj x1 | | | +--> webobj x2 | +--> webobj x3 In this case there should be a way to access the webobjects of the page like this: page->x->x1->x2 page->x->x2->x1 page->x->x2->x2 (Currently they can be accessed only like this: page->x, page->x1, page->x2, which does not allow two webobjetcs to have the same name (or ID).) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 10:11:01
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127172 By: dashohoxha Improve the structure of the framework and the application so that two independent applications can comunicate easily with each other. E.g. one of the applications can include the other (like a webbox that can include another webbox) and both of them work independently in the same window. One of the applications can check or modify the state of the other application, can modify its behaviour, can use its resources (images, templates, etc.), etc. Such a capability would be useful for applications like "browse", which browses and displays the templates of another application (actually 'browse' is implemented like a tool, or a webbox that is not totally independent from the application that it browses). It may also be useful for "tidy", an application that rewrites the templates of an egzisting application in XHTML format, with good indentation etc. It will also be useful for the WADE (Web Application Development Environment), so that it is an independent application and doesn't have to be mixed with the framework or with the application that is being built. In order to achieve this: * Path constants, Option constants, Debug constants etc should not be constants, because the value of the constants cannot be changed. * An event should tell (either implicitly or explicitly) to which application belongs, so that the framework can dispatch it to the correct webbox. * etc. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 10:07:42
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127168 By: dashohoxha Add page caching support to the framework. Before processing the templates, the framework should check whether the requested page is already in the cache (the cache folder is specified by the constant CACHE_PATH in 'const.Paths.php'). Each component (WebBox or WebObject) should be cached separately because this reduces the size of the cache. If there is a component that cannot be cached, because it interacts with the DB, then the framework will parse and render it. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 10:05:08
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127162 By: dashohoxha Would it be better if we can access the templates and recordsets of the $webPage like this: ? $webPage->"tpl_$tpl_id"; $webPage->"tpl_$wb_id"; $webPage->"rs_$rs_id"; and then: $webPage->"tpl_$wb_id"->$sub_wb_id; $webPage->"tpl_$tpl_id"->$sub_wb_id->$sub_sub_wb_id; $webPage->"tpl_$tpl_id"->$sub_wb_id->$sub_sub_wb_id->parent; $webPage->"rs_$rs_id"->MoveNext(); $webPage->"rs_$rs_id"->fld_name; ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 09:59:40
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127155 By: dashohoxha It may be useful that the webobjects also have functions like: $this->constructor(); $this->destructor(); which are called by the framework after the object is created and before it is destroyed. The destructor can be called just before the session vars are saved, so that it has the possibility to remove its state vars from the session by calling WebObject::destroy(), which is the oposite of WebObject::init(). When WebObject::destroy() is called, it removes all the state vars from the session, so that next time that this webObj is parsed, it will be initialized again ($this->init() will be called again). Probably it is better to rename: $this->init() to $this->initState() and WebObject::destroy() to WebObject::destroyState() ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 09:53:28
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127147 By: dashohoxha A "TableRS" is an editable RS which is associated with a table in a DB. After editing this RS, the programer can save the changes back to DB. For example: //open the recordset $fld_list = "field1, field2, field3"; //optional, default "*" $condition = "... AND ... OR ..."; //SQL WHERE condition, optional $rs = new TableRS("tbl_name", $fld_list, $condition); //make some changes to the recordset $rs->MoveNext(); $rs->rmRec(); //remove the second record $rs->find("field1='$value'"); do { $rs->setFld("field2", $value2); } while ($rs->find_next()); $rs->MoveLast(); $rec = array("field1"=>$val1, "field2"=>$val2, "field3"=>$val3); $rs->addRec($rec); //save in the DB table all the changes made to the recordset $rs->save(); ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 09:29:42
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127125 By: dashohoxha Change the names of some vars, classes, functions etc. so they describe better the function, class, etc. - {{obj_name}} to {{Name}} {{class_name}} to {{Class}} - Rename path constants from 'XYZ_PATH' to 'XYZ/'. - Change from: GoTo("page1.html?event=webclass::webobj.event_name(arg1;arg2;arg3)") to: GoTo("page1.html//webclass::webobj->event_name(arg1,arg2,arg3)") - Probably it is better to change the denotation of a slot (a variable) from {{var_name}} to a more familiar denotation like: ${var_name}, or something like this. (Why is it better? Does it have any disadvantages?) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 09:13:53
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127110 By: dashohoxha The GNU system has i18n support (gettext) and PHP has an API for it, however something does not work very well for web applications, so I think that the framework cannot use it. We can build, however, something similar to it. The messages that have to be translated by the framework can be denoted like this: {{i)Hello World!}} Then a tool similar to xgettext can be used to extract all the messages from the templates. Then we can either continue in the same way that gettext does, or we can create a message file for each webbox. In the second case we will have to create the files 'boxid_fr.msg', 'boxid_de.msg' etc. for each webbox and for each language. They can either be stored in the same folder as the webbox, or in the subfolder 'langs' in the same folder, or in the folder 'messages' where are stored all the message files of the application, etc. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 08:56:50
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127084 By: dashohoxha For accessing the state vars of a webobj we use this syntax: $s_var = $this->getSVar("varName"); Probably it would be more convenient to use this syntax: $s_var = $this->varName; or $s_var = $this->s_varName; (to emphasize the difference between state vars and any other usual (non-persistent) vars that the webobj might have) However, $this->s_varName = "new_var_value"; cannot be better (in functionality) than $this->setSVar("varName", "new_var_value"); because the value changed in the first one will be available after $this->onParse(), and the second one changes it everywhere immediately. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 08:52:44
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127079 By: dashohoxha Add this functionality to the framework: any webobject can handle an event sent to another webobject, if it defines the event handler "on_className_eventName()" (usually the event handlers are named like this: "on_eventName()"). Here 'eventName' is the name of the event, and 'className' is the class of the webobject that receives or sends the event (whichever is more appropriate). This may make obsolete the "event_target='any'", which was used to allow a webbox to handle the events of another webbox. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 08:36:08
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127052 By: dashohoxha The state var 'objID->initialized' is used to see whether a webobj is initialized or not, and it has a value 'true' or 'false'. Instead of it we can keep a state var that is more useful, e.g. 'objID->class_path' which keeps the path of the PHP code of the webclass. This path can help to run the event handler for the $event before the parsing starts at all. This also allows to run the event handler of a webobj that is not parsed at all (at present, the framework runs the event handler of a webobj just before parsing it, and it cannot run it if the webobj is not parsed). We can also call 'objID->class_path' with another name and keep in it other usefull info about the webobj and its state, e.g ??. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 08:25:33
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2127041 By: dashohoxha <xmp> Add to the framework the possibility for defining new tags ----------------------------------------------------------- Like this: <TagDefinition name="Tag1"> <Attrib name="attr1" /> <Attrib name="attr2" default="val1"/> <!--# the template of the tag #--> attr1='{{attr1}}'<br> attr2='{{attr2}}'<br> Tag Body: <xmp> {{ElementContent}} </xmp> <p> The variable tplVar='{{tplVar}}' is declared in the PHP code of the tag definition. </p> <!--# . . . . . . . . . . . #--> </TagDefinition> Tag declarations: <Tag1 attr1="val1" attr2="val2"> <!--# element content here #--> </Tag1> <Tag1 attr1="xxxx"> <!--# element content here #--> </Tag1> The PHP code of the tag definition (file 'Tag1.php'): <? class Tag1 extends Tag { function onParse() { } function onRender() { WebApp::addVar("tplVar", "*******"); } } ?> Example: <TagDefinition name="Box"> <Attrib name="title" /> <Attrib name="border_color" default="#aaaaff" /> <Attrib name="body_color" default="white" /> <table border="0" cellspacing="1" cellpadding="3" bgcolor="{{border_color}}"> <tr> <td align="middle"> <strong>{{title}}</strong> </td> </tr> <tr> <td bgcolor="{{body_color}}"> {{ElementContent}} </td> </tr> </table> </TagDefinition> <Box title="Select By Status"> <Repeat rs="status"> <input type="checkbox" name="{{status_name}}" value="{{status_id}}" onClick="update_selectedStatus()"> {{status_name}} </Repeat> </Box> <Box title="Test Box" border_color="blue"> <p> This is the <b>content</b> of the element (tag) <Box>. </p> <p> It will be displayed inside a <b>blue</b> box, with a blue border and a blue title bar, while the background of the body will be <b>white</b> (the default value). </p> <p> The title in the titlebar will be "Test Box". </p> </Box> The <TagDefinition> will be like a template that will be used to transform a simple tag (the tag that it defines) into a more complex HTML code. This will hopefully make easier the work of graphical designer and web developer. It will also be a step towards using XML content in the application (the transformation to HTML will be done by the framework using the tag definitions for each tag of the XML (for each tag mentioned in the DTD of the document). So, while the <Repeat> etc. are usually used to display DB content (to convert a query result into HTML), the <TagDefinition> can be used to display XML content (to transform an XML content to HTML). </xmp> ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: SourceForge.net <no...@so...> - 2003-07-30 07:43:29
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2126973 By: dashohoxha Add an optional feature to the framework (which is set ON when a constant in 'const.Settings.php' is set 'true'), such that the generated HTML page contains information to make possible the reverse engineering of the templates. The reverse engineering will be done by a utility program (in PHP) which will take this HTML page and will generate the templates that were originally used to construct this page. This tool will be useful for allowing the graphical designer to work on the HTML page as a whole, instead of working on separate templates individually, and then repartition the resulting page automatically into templates. (Sometimes this may be useful, e.g. when the graphical designer wants to take advantage of advanced features of HTML editors for rewriting the whole HTML code of the page automatically, or for checking it for errors.) ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=135220 |
|
From: Dashamir H. <dh...@in...> - 2003-07-30 07:16:45
|
This list is for discussing new ideas about how to improve the phpWebApp framework. Both developers and users can participate in the discussion.=20 After these ideas are reviewed and elaborated, their advantages and disadvantages become clear, their positive and negative sides are weighte= d etc., some of them may become mature and will be included as ToDo tasks f= or being implemented and tried in the near future. There is also the forum "phpWebApp Improvments": https://sourceforge.net/forum/forum.php?forum_id=3D135220 with the same purpose (discussing new ideas) as this list. The discussion will be more dynamic in this list, while the ideas will be more structure= d and organized in the forum. |
