I am currently looking into how I could suggest that wikindx might design its new resource input procedure/form.
I thought about using a dynamic form instead of the multiple stages from v3. But before I tinker on, I am wondering if the dynamics should be implemented on the client's side (and thus probably not work when Javascript is disabled in the user's browser) or on the server side.
Examples for both, although in german, could be found
.
The server-side example is similar to what happens now - a multi-stage process where each page depends on the preceding page choices.
More and more in wikindx requires javascript (I'm thinking about AJAX too) and a one-stage process using javascript would be highly beneficial with this function (one of the more time-consuing ones in wikindx). How many browsers have javascript disabled these days? We can make it a requirement.
The javascript would need to pick up the resource fields as defined in the resource map files (which I'm thinking of shifting to XML because I want to explore the possibility of admins creating their own resources (and fields) as they can create their own XML style files).
BTW - did you get my email to your Frankfurt University address from my work address?
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've indeed gotten your email from univ. to univ. accounts. Don't know what is up with the (my?) sf.net account. Sorry for not replying to that explicitly.
I have an inclination to play with javascript, too. I'll let you know when I have something that can be shown. In the meantime, you can monitor my attempts at . I hope I did everything right in adding that module…
I have a new module core/modules/resource/RESOURCENEW.php and modified core/navigation/MENU.php so that the new resource menu item links to 'index.php?action=resource_RESOURCENEW_CORE'
then, in RESOURCENEW.php, I've copied lots of stuff from RESOURCEVIEW.php and have now the following init function:
public function init($message = FALSE)
{
$this->userId = $this->session->getVar('setup_UserId');
$this->myAddResource($message);
}
then, I've modified templates/default/content.tpl and added {assign var=addResourceFields value=$addResourceFields|default:false}
to the top and
{* START NEW RESOURCE FORM DISPLAY *}
{if $addResourceFields}
<tr>
<td>
{* include newform.tpl *}
{include file = 'newform.tpl'}
</td>
</tr>
{/if}
{* END NEW RESOURCE FORM DISPLAY *}
right above the optional list navigation links.
Finally, I am working in templates/default/newform.tpl, where I have - as of now - a plain html form.
I am planning to construct lists of input elements in RESOURCENEW.php and pass these to the template as addResourceFields array or object. Next will be modifying them with jscript.
Is that a reasonable approach?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Congratulations on understanding my coding without documentation (still to be written of course)! Can I suggest you call it resourceNew.tpl in the likely event that we may have other such forms (such as styleNew.tpl)?
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mark,
I did the renaming and do have a basic ajax setup now (with xajax framework) - upon change of the dropdown menu, a server-side routine is called that changes the pre-selection of a plain input element. However, the point of ajax, it seems to me, would be that those server-side routines access the database and so on. Does that mean that I would need to make the ajax-called php page so that it loads a class instance and all that stuff? (I'm a bit worried about performance in that case, although I have no actual experience how that would play out.) For now, it merely contains the following php code (I hope I got the markdown formatting right this time):
<?php
// here is our xajax class setup included:
include("RESOURCENEW.common.php");
/*functions registered:
getResourceFields
getCreatorFields
getDataByISBN
getDataByName
getDataByCollection
*/
function getResourceFields($aFormValues)
{
$objResponse = new xajaxResponse();
// include_once('../../resources/RESOURCEMAP.php');
// $resourceMap = new RESOURCEMAP;
// $resourceFields = $resourcemap->$aFormValues;
$objResponse->assign("vorname","value",$aFormValues);
return $objResponse;
}
function initLayout($aFormValues)
{
global $smarty;
$objResponse = new xajaxResponse();
// Anstelle von ->display() wird der Inhalt mit ->fetch() geholt
$html = $smarty->fetch("layout.tpl");
// zuweisen des HTML-Codes
$objResponse->assign("layout","innerHTML",$html);
return $objResponse;
}
?>
(I only use the first one, the second function is merely a note to self.)
Cya,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To explain a bit more: According to some tutorial, I've splitted the ajax stuff in three files, one of which sets up ajax (resourcenew.common.php) and is included by the "normal" page (resourcenew.php). Ajax then calls resourcenew.server.php in the background and does stuff to the "client" page with the data it receives. What exactly it does depends on the xajax function that are called in resourcenew.server.php (like assign some value to an element's property (assign(element, property, value). There are a couple of other functions that xajax provides and its advantage is that it then generates the needed javascript parts automatically, so all the coding is done in php. *When* ajaxs kicks in of course depends on the "client" page, where I am generating the select box in a php function and assign an ajax function to its onChange event:
I haven't had a chance to look at ajax yet. However, my understanding is that it will alter elements on a page according to the selection of other elements on that same page. E.g. the user selects the resource type then ajax displays (one the same page) the fields for selection of number of authors, editors etc. then, as they are selected, the same page displays the further fields that are currently on the final page of wikindx.
That way, everything could be done on one page. In terms of ajax dealing with the database/server, I don't believe that would be any different to the user hitting 'submit' for each of the three pages currently required. Also, hitting the menu item for 'new resource', the script could gather everything it needs in one call then depending upon user choices, simply sift through that data in javascript alone for the appropriate fields and data to display. In fact, this is probably not ajax at all but simply javascript.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
right - upon selection in one element, there's a javascript executing which alters another (or the same) element on the same page. ajax is that this javascript can communicate with the server in the background. (And xajax lets you explain what you want in php and have the php server generate the necessary javascript and insert it in the page.)
For our present purpose (one single new-resource-page) this means that we could either define everything (like an array: resource_type - array(field names)) for all types and have the javascript hide or show elements according to user action. (DHTML and probably much javascript programming needed) Or we could keep it a three-step process with queries to the server between each step but do that in the background and *still keep it all on one page* (ajax).
I am inclined to try the second option. (And so have an ajax framework ready that could also eventually be used to retrieve other information, say when the user enters an isbn or doi.)
Now where I am reluctant ATM is this: the browser with the client page (resourcenew.php) loaded makes ajax send off a query in the background to another URI (resourcenew.server.php) and then, using the results, does something to the client page. In order for the background process to be hardly noticeable, it should not introduce much delay, which is why I wonder how to access the database (in resourcenew.server.php) with as little overhead as possible. After all, this is for comparatively limited purposes and probably we don't need all of all those classes that are instantiated in the client page:
In answer to the second, to access the database, all you really need is FACTORY_DB. However, there is little overhead in loading those other classes assuming the class has already been loaded elsewhere in the PHP call because, if the class has already been loaded, FACTORY simply returns a pointer to that class.
Re the two methods of getting fields for each resource, I don't think it really matters. Don't forget, the acceptable fields for each type of resource are already defined in RESOURCEMAP.php. I'd go for a two stage process: select type of new resource, ajax loads potential fields from RESOURCEMAP.php for that resource. Before displaying them, it asks for the number and type of creators - based on that, it then displays the appropriate form elements from the already loaded ajax call. There will be common form elements such as notes, abstract, URLs etc.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Just as a sidenote, AFAIU, from the perspective of the server the incoming ajax query is a normal http request which just doesn't go to index.php but directly to core/modules/resource/resourcenew.server.php - which is why I am not sure how much of the classes and factory has to be newly loaded. From the perspective of the server, it could just as well be a completely different user who just happened to type http://…/resourcenew.server.php in the adress bar of his browser. The same reloading (or not) has to happen for RESOURCEMAP.php, too. Anyway, we can just wait and see how it turns out. I just meant to make sure not to head a completely wrong direction from the outset.)
I'll keep you posted,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi again,
I've got the first step (loading fields array upon change of resource type) working somewhat - next I need to fill in all the fields, handle the layout and link them to the database. I think I will add a '+' field below the author input row(s) that you can click to add another row. And I will have to study the old code to see how to get from one author ID to several plaintext input fields (and vice versa).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you give me a hint how the user input should get from the form elements into the database? In wikindx3 this seems to go through session variables, does it? Would it make sense to contruct an SQL INSERT statement (after sanity checks) from the submit button and skip the detour via environment variables? Or why would the environment variables need to be set?
OTOH, I'm afraid I am going to put more time into the presentation I had been talking of. So progress is going to be slower… But if you want to have a look at some piece of it, just tell me how to get it to you.
See you,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I used session variables to store input data so that, if the user made a mistake (not enteruing a required field), the form could be returned with fields already filled out. I imagine javascript could handle this validation/sanity check so no need to use session variables.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2011-02-01
Has there been any thought for using jQuery for the javaScript? It seems well established. If v4 (or even v5 since v3 is the current distro and v4 is 2 years old….) has a new CSS based template or a UI template I would be willing to work on that. I come from a WordPress background, I was looking for a them or template file to edit but It was not obvious to me where it was located or if it was located in several locations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v4 is not 2 years old ;) It's yet to be born but is (slowly) being birthed. If I understand jQuery correctly, it's a form of AJAX. I've already implemented a form of AJAX in v4 and it's being used for a range of forms but in particular the resource input/edit page. You can have a look at it by getting the current SVN.
If you're familiar with javascript (more so than I am) and are volunteering to work on wikindx (thanks!) I can certainly think of things for you to do.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to confirm, v4's new resource page is now all on one page (rather than 3) and uses AJAX. Various other forms (such as search and select) also use AJAX.
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
(Thanks Mark for opening the forum)
I am currently looking into how I could suggest that wikindx might design its new resource input procedure/form.
I thought about using a dynamic form instead of the multiple stages from v3. But before I tinker on, I am wondering if the dynamics should be implemented on the client's side (and thus probably not work when Javascript is disabled in the user's browser) or on the server side.
Examples for both, although in german, could be found
.
Any opinions?
TIA,
Andreas
: http://www.ohne-aktive-inhalte.de/codebeispiele/dynamisches_formular/index.html
Hi Andreas,
My German is terrible.
The server-side example is similar to what happens now - a multi-stage process where each page depends on the preceding page choices.
More and more in wikindx requires javascript (I'm thinking about AJAX too) and a one-stage process using javascript would be highly beneficial with this function (one of the more time-consuing ones in wikindx). How many browsers have javascript disabled these days? We can make it a requirement.
The javascript would need to pick up the resource fields as defined in the resource map files (which I'm thinking of shifting to XML because I want to explore the possibility of admins creating their own resources (and fields) as they can create their own XML style files).
BTW - did you get my email to your Frankfurt University address from my work address?
Mark
Hi Mark,
I've indeed gotten your email from univ. to univ. accounts. Don't know what is up with the (my?) sf.net account. Sorry for not replying to that explicitly.
I have an inclination to play with javascript, too. I'll let you know when I have something that can be shown. In the meantime, you can monitor my attempts at . I hope I did everything right in adding that module…
CU,
Andreas
: http://www.commontology.de/wikindx4/index.php?action=resource_RESOURCENEW_CORE
Hi Andreas,
Great to have someone else working on this! Where have you added the module in the file system?
Mark
I have a new module core/modules/resource/RESOURCENEW.php and modified core/navigation/MENU.php so that the new resource menu item links to 'index.php?action=resource_RESOURCENEW_CORE'
then, in RESOURCENEW.php, I've copied lots of stuff from RESOURCEVIEW.php and have now the following init function:
public function init($message = FALSE)
{
$this->userId = $this->session->getVar('setup_UserId');
$this->myAddResource($message);
}
private function myAddResource($message = FALSE)
{
$this->template->tpl->assign('displayMenu', FALSE);
$multiUser = $this->session->getVar('setup_MultiUser');
if($multiUser)
$this->template->tpl->assign('multiUser', TRUE);
$this->addResourceFields=array("resourceTypesSelect" => $this->resourceMap->types);
$this->template->tpl->assign('addResourceFields', $this->addResourceFields);
print_r($this->addResourceFields);
}
then, I've modified templates/default/content.tpl and added {assign var=addResourceFields value=$addResourceFields|default:false}
to the top and
{* START NEW RESOURCE FORM DISPLAY *}
{if $addResourceFields}
<tr>
<td>
{* include newform.tpl *}
{include file = 'newform.tpl'}
</td>
</tr>
{/if}
{* END NEW RESOURCE FORM DISPLAY *}
right above the optional list navigation links.
Finally, I am working in templates/default/newform.tpl, where I have - as of now - a plain html form.
I am planning to construct lists of input elements in RESOURCENEW.php and pass these to the template as addResourceFields array or object. Next will be modifying them with jscript.
Is that a reasonable approach?
Hi Andreas,
Congratulations on understanding my coding without documentation (still to be written of course)! Can I suggest you call it resourceNew.tpl in the likely event that we may have other such forms (such as styleNew.tpl)?
Mark
Hi Mark,
I did the renaming and do have a basic ajax setup now (with xajax framework) - upon change of the dropdown menu, a server-side routine is called that changes the pre-selection of a plain input element. However, the point of ajax, it seems to me, would be that those server-side routines access the database and so on. Does that mean that I would need to make the ajax-called php page so that it loads a class instance and all that stuff? (I'm a bit worried about performance in that case, although I have no actual experience how that would play out.) For now, it merely contains the following php code (I hope I got the markdown formatting right this time):
<?php
// here is our xajax class setup included:
include("RESOURCENEW.common.php");
/*functions registered:
getResourceFields
getCreatorFields
getDataByISBN
getDataByName
getDataByCollection
*/
function getResourceFields($aFormValues)
{
$objResponse = new xajaxResponse();
// include_once('../../resources/RESOURCEMAP.php');
// $resourceMap = new RESOURCEMAP;
// $resourceFields = $resourcemap->$aFormValues;
$objResponse->assign("vorname","value",$aFormValues);
return $objResponse;
}
function initLayout($aFormValues)
{
global $smarty;
$objResponse = new xajaxResponse();
// Anstelle von ->display() wird der Inhalt mit ->fetch() geholt
$html = $smarty->fetch("layout.tpl");
// zuweisen des HTML-Codes
$objResponse->assign("layout","innerHTML",$html);
return $objResponse;
}
?>
(I only use the first one, the second function is merely a note to self.)
Cya,
Andreas
argh - markdown again changed my smaller-than and greater-than signs. Sorry for that
To explain a bit more: According to some tutorial, I've splitted the ajax stuff in three files, one of which sets up ajax (resourcenew.common.php) and is included by the "normal" page (resourcenew.php). Ajax then calls resourcenew.server.php in the background and does stuff to the "client" page with the data it receives. What exactly it does depends on the xajax function that are called in resourcenew.server.php (like assign some value to an element's property (assign(element, property, value). There are a couple of other functions that xajax provides and its advantage is that it then generates the needed javascript parts automatically, so all the coding is done in php. *When* ajaxs kicks in of course depends on the "client" page, where I am generating the select box in a php function and assign an ajax function to its onChange event:
onchange='xajax_getResourceFields(this.options.value);return false;')
Hi Andreas,
I haven't had a chance to look at ajax yet. However, my understanding is that it will alter elements on a page according to the selection of other elements on that same page. E.g. the user selects the resource type then ajax displays (one the same page) the fields for selection of number of authors, editors etc. then, as they are selected, the same page displays the further fields that are currently on the final page of wikindx.
That way, everything could be done on one page. In terms of ajax dealing with the database/server, I don't believe that would be any different to the user hitting 'submit' for each of the three pages currently required. Also, hitting the menu item for 'new resource', the script could gather everything it needs in one call then depending upon user choices, simply sift through that data in javascript alone for the appropriate fields and data to display. In fact, this is probably not ajax at all but simply javascript.
Mark
Hi Mark,
right - upon selection in one element, there's a javascript executing which alters another (or the same) element on the same page. ajax is that this javascript can communicate with the server in the background. (And xajax lets you explain what you want in php and have the php server generate the necessary javascript and insert it in the page.)
For our present purpose (one single new-resource-page) this means that we could either define everything (like an array: resource_type - array(field names)) for all types and have the javascript hide or show elements according to user action. (DHTML and probably much javascript programming needed) Or we could keep it a three-step process with queries to the server between each step but do that in the background and *still keep it all on one page* (ajax).
I am inclined to try the second option. (And so have an ajax framework ready that could also eventually be used to retrieve other information, say when the user enters an isbn or doi.)
Now where I am reluctant ATM is this: the browser with the client page (resourcenew.php) loaded makes ajax send off a query in the background to another URI (resourcenew.server.php) and then, using the results, does something to the client page. In order for the background process to be hardly noticeable, it should not introduce much delay, which is why I wonder how to access the database (in resourcenew.server.php) with as little overhead as possible. After all, this is for comparatively limited purposes and probably we don't need all of all those classes that are instantiated in the client page:
$this->db = FACTORY_DB::getInstance();
$this->vars = GLOBALS::getVars();
$this->config = FACTORY_CONFIG::getInstance();
$this->stmt = FACTORY_SQLSTATEMENTS::getInstance();
$this->errors = FACTORY_ERRORS::getInstance();
$this->messages = FACTORY_MESSAGES::getInstance();
$this->table = FACTORY_TABLE::getInstance();
$this->form = FACTORY_FORM::getInstance();
$this->html = FACTORY_HTML::getInstance();
$this->stats = FACTORY_STATISTICS::getInstance();
$this->session = FACTORY_SESSION::getInstance();
$this->user = FACTORY_USER::getInstance();
$this->template = FACTORY_TEMPLATE::getInstance();
$this->badInput = FACTORY_BADINPUT::getInstance();
$this->common = FACTORY_RESOURCECOMMON::getInstance();
Should I try to merely trim the list of classes to get to the minimum, or rather take an altogether different approach to open the database?
Thanks for the time you're taking in discussing this.
Andreas
Hi andreas,
In answer to the second, to access the database, all you really need is FACTORY_DB. However, there is little overhead in loading those other classes assuming the class has already been loaded elsewhere in the PHP call because, if the class has already been loaded, FACTORY simply returns a pointer to that class.
Re the two methods of getting fields for each resource, I don't think it really matters. Don't forget, the acceptable fields for each type of resource are already defined in RESOURCEMAP.php. I'd go for a two stage process: select type of new resource, ajax loads potential fields from RESOURCEMAP.php for that resource. Before displaying them, it asks for the number and type of creators - based on that, it then displays the appropriate form elements from the already loaded ajax call. There will be common form elements such as notes, abstract, URLs etc.
Mark
Hi Mark,
thanks for the reply. I'll see how far I can get.
(Just as a sidenote, AFAIU, from the perspective of the server the incoming ajax query is a normal http request which just doesn't go to index.php but directly to core/modules/resource/resourcenew.server.php - which is why I am not sure how much of the classes and factory has to be newly loaded. From the perspective of the server, it could just as well be a completely different user who just happened to type http://…/resourcenew.server.php in the adress bar of his browser. The same reloading (or not) has to happen for RESOURCEMAP.php, too. Anyway, we can just wait and see how it turns out. I just meant to make sure not to head a completely wrong direction from the outset.)
I'll keep you posted,
Andreas
If a user could just type the address and get access to add a new resource, then use core/miscellaneous/GATEKEEP.php:
$this-&gt;common = FACTORY_GATEKEEP::getInstance();
Mark
Hi again,
I've got the first step (loading fields array upon change of resource type) working somewhat - next I need to fill in all the fields, handle the layout and link them to the database. I think I will add a '+' field below the author input row(s) that you can click to add another row. And I will have to study the old code to see how to get from one author ID to several plaintext input fields (and vice versa).
Impressive.
Mark
Hi Mark,
Can you give me a hint how the user input should get from the form elements into the database? In wikindx3 this seems to go through session variables, does it? Would it make sense to contruct an SQL INSERT statement (after sanity checks) from the submit button and skip the detour via environment variables? Or why would the environment variables need to be set?
OTOH, I'm afraid I am going to put more time into the presentation I had been talking of. So progress is going to be slower… But if you want to have a look at some piece of it, just tell me how to get it to you.
See you,
Andreas
Hi Andreas,
I used session variables to store input data so that, if the user made a mistake (not enteruing a required field), the form could be returned with fields already filled out. I imagine javascript could handle this validation/sanity check so no need to use session variables.
Mark
Has there been any thought for using jQuery for the javaScript? It seems well established. If v4 (or even v5 since v3 is the current distro and v4 is 2 years old….) has a new CSS based template or a UI template I would be willing to work on that. I come from a WordPress background, I was looking for a them or template file to edit but It was not obvious to me where it was located or if it was located in several locations.
Hi,
v4 is not 2 years old ;) It's yet to be born but is (slowly) being birthed. If I understand jQuery correctly, it's a form of AJAX. I've already implemented a form of AJAX in v4 and it's being used for a range of forms but in particular the resource input/edit page. You can have a look at it by getting the current SVN.
If you're familiar with javascript (more so than I am) and are volunteering to work on wikindx (thanks!) I can certainly think of things for you to do.
Mark
Just to confirm, v4's new resource page is now all on one page (rather than 3) and uses AJAX. Various other forms (such as search and select) also use AJAX.
Mark