|
Bug Notes |
|
|
anonymous
|
|
2003-11-25 00:28
|
|
Other idea (more simple to implement ?) :
The phpMyEdit customizer should put some well documented phpMyEdit call into the HTML template as : (only example, should be defined by the phpMyEdit developper team)
insert_filed("FieldName");
insert_button("OK", "Validation");
insert_tab_bar("TabName", "TabLabel", "ImgUrl");
fred @ a2m2.ch |
|
|
|
|
Well, this seemsto be really difficult job.
I would like to see here more ideas and thoughts. |
|
|
|
|
My idea is not to create some new complexe structures, but use your existing phpMyEdit code to create "view/edit record" forms drived by a HTML template.
The best way remain open to be the more easy to implement for you.
Perhaps it's just some directive how to use some internal phpMyEdit calls into custom pages.
1) Static way :
The template is only a text file given as a parameter (new parameter ie :
$opts['template']['add']= 'add_filename.htm';
$opts['template']['change']= 'change_filename.htm';
)
You read the template to generate the displayable HTML page with right fields generated when you encounter some defined tags (you defined the tags and rules to place tags to be the more easiest to you).
2) dynamic way
The html page is a PHP page with embeded phpMyEdit calls. You defined the calls names and rules (perhaps some initialisation, naming convention, specifics id or name attributes,...).
The called PHP page is defined by parameter(new parameter ie :
$opts['template']['add']= 'add_filename.php';
$opts['template']['change']= 'change_filename.php';
)
3) structured way
You defined some fixed structure to build "view/edit record" forms.
I think we need the ability to define all <TABLE> parameters to build multicolumn entry forms with label, fields or empty <TD> formated by CSS.
The parameters will be more complex, but perhaps (not sure ! ) more easy to implement for you (ie
$opts['layout']['add']['column1']['width']= '80';
$opts['layout']['add']['column2']['width']= '40';
$opts['layout']['add']['column3']['width']= '80';
$opts['layout']['add']['column4']['width']= '40';
$opts['layout']['add']['row1']['column1']['label']= 'Free Label 1';
$opts['layout']['add']['row1']['column1']['name']= 'ID_LABEL_A';
$opts['layout']['add']['row1']['column2']['fiels']= 'FIELD_NAME_1';
$opts['layout']['add']['row1']['column2']['name']= 'ID_LABEL_B';
$opts['layout']['add']['row1']['column3']['label']= 'Free Label 2';
$opts['layout']['add']['row1']['column3']['name']= 'ID_LABEL_A';
$opts['layout']['add']['row1']['column4']['width']= 'FIELD_NAME_2';
$opts['layout']['add']['row1']['column4']['name']= 'ID_LABEL_B';
etc...
etc...
etc...) |
|
|
|
|
sory the Add Bugnote modify my comment !
Just replace all ’ by single quote. |
|
|
|
|
After some reflexions, I think the dynamic way is the best and no so difficult to implement.
1) the calling program set the phpMyEdit options (including ['template']=file_name.php)
2) it call phpMyEdit normaly with : new phpMyEdit($opts);
3) phpMyEdit do all the needed initialisation, read database,...
4) if template is set, phpMyEdit call/include the template file_name.php
5) the file_name.php generate all the needed HTML and when phpMyEdit structures are requires it call some predefined functions. I think than only few functions are needed :
function phpMyEdit_StartForm(); // to initialise HTML form
function phpMyEdit_InsertField( FIELD_NAME [,options?] ); // to create needed HTML/Javascript for this field
function phpMyEdit_GetLabel( FIELD_NAME [,options?] ); // to get field label (or direct access to phpMyEdit var)
function phpMyEdit_GetHelp( FIELD_NAME [,options?] ); // to get field help (or direct access to phpMyEdit var)
function phpMyEdit_InsertButton( BUTTON_CODE [,options?] ); // to create the button
function phpMyEdit_CloseForm(); // to close HTML form
6) at the end of the file_name.php execution, the phpMyEdit finish all the task to termine corectly the job.
This dynamic way give us the oportunity to do the right layout, do some contextual operations based on the curent record data as calculations, conditionnal field display, multiples tabs, pictures, dynamic URL (for example calling another phpMyEdit file with filter set to curent record ID), pop-up contextual help,...
For more ideas, comments about implementation options, discussions contact me by mail and we put the conclusion of our mail interactions here in a new bugnote as synthesis. |
|
|
|
|
this job has at least two difficulties.
1st is to give good variable names to each possible variable. the ones i see(not in LF mode):
- buttons(add, more, cancel,...)
- form and page begginings (tags, hidden variables, and other non-visible things)
- form and page ends (..)
- table beggining and end
- real text to be outputed (name, value, help, css for each)
(did i miss any ? that does not seem to be that much)
2nd is to implement this in PME.
current html template could be reached by echoing:
form beggining
table beggining
buttons
foreach(columns) name, variable, help
buttons
table end
form end
problems i see: make all hidden variables appear at one place, agreement on whether variable or functions should be used.
what i suggest: make an agreement on variable/function structure, _after_ that start gradually rewriting code to limit number of echo-s and grouping them according to the agreed on variable structure. |
|
|
|
|
I don't be sure it was so difficult.
The HTML header and footer should be created as we need in the calling program.
The <form> and all the generated javascript should remain under phpMyEdit control.
What we need is to generate corectly (by phpMyEdit technical users) the html <form> inner content.
I try to do the job but it's to many changing for my pore PHP knowledge.
Change should be done with 2 steps :
1) changing a little the curent functions structures (with the same functionalities)
2) adding the template functionality
I try to explain here (with some like PHP code lines) :
1) changing the curent functions
We need to rewrite a more general display_record() function, using a global var I'll call $OP for this explain.
Value for $OP represent the curent operation 'add', 'copy', 'change' or 'delete'.
Using some switch statements this function should replace display_add_record(), display_copy_change_delete_record() and display_change_field().
We need to rewrite a genral display_field($k) function also based on $OP variable and field($k) type.
This function should call more specialized functions display_xxxx_field() for each kind of field/operation.
Now the display_record() function look like :
function display_record()
{
switch($OP) ...initialising specific statements
// SQL reading, CSS initialising,...
for $k
{
echo <tr><td>name</td>
echo <td>
display_field($k)
echo </td>
echo <td>help</td></tr>
}
switch($OP) ... ending statements if needed
}
=> at this point the actual functionalities remain exactly the same
2) adding the template functionality
A new function generate_field('field_name') was responsible to :
- remember witch fields are generated (we don't need to generate later hidden field for them)
- call display_field() with the right $k
We should also create generate_name('field_name') and generate_help('field_name'), but direct access to phpMyEdit variables are also possible for this purpose.
The template should only call those functions. (other function should be writen later if we need to generate buttons !)
Now the display_record() function should be modified to :
function display_record()
{
switch($OP) ...initialising specific statements
// SQL reading, CSS initialising,...)
if ( template ) // new customisable form
{
switch($OP) ... include (the right) template.php
// template.php only call generate_xxx() functions
for $k ...generate needed hidden fields
//for not yet generated fields
}
else for $k // normal part
{
echo <tr><td>name</td>
echo <td>
display_field($k)
echo </td>
echo <td>help</td></tr>
}
switch($OP) ... ending statements if needed
}
=> at this point the html structure of the <form> should be free customisable by phpMyEdit technical users.
=> navigations and buttons remain as actualy, but perhaps somebody have an idea for them ? |
|
|
|
|
after a while of thinking i came to this model:
change every 'echo "something";' to '$this->echo(true, "variable_name", "something"); '
where true is for normal data, false is fo '<td>' and stuff like that
"variable_name" is a name of variable by which this data will be adressed
"something" is what is to be echoed/asigned to variable
somewhere there will be a switch template = 1 / 0 if (1 ) data will be assigned to variable, if(0) data will be echoed.
the main calling script would look like:
$opts['template'] = true;
MyForm = new phpMyEdit.class($opts);
$data = MyForm->return_variables();
echo $data['rm_beggining'];
echo $data['button']['save']; or echo $data['button_save'];
....
however it would be nicer to have a tmpl file to generate this... any idea how ? |
|
|
|
|
Michael, the solution above is a "HTML template" oriented way. It cut the template into 3 parts :
- the header part (in the calling program)
- the inner <form> part (the proposed modifications)
- the tailer part (in the calling program)
Only the navigation and the buttons are not fully customisable in this proposition.
I think(*) than your model doesn't allow to display conditionnaly a field depending on an other field contents, display picture or multimedia elements based on field contents, implement tabs based on layers,...
And the technical phpMyEdit user need to know all the variables where to find informations and some time use it, some time no. What about fields not used in some case (how to generate hidden structures) ? What about generating javascript part ?
I think than it will be now intresting to have nepto opinion about this discussion.
Perhaps I miss some important phpMyEdit concepts and my proposal is nonapplicable.
(*)Perhaps I don't right understand your model.
What are the phpMyEdit specialist comments ? |
|
|
|
|
conditional displaying : you can do if($data[row][somefield] !=5 ) echo $data[row][somefield]; but i think all formating should be done by pme options, only final look of the page should be done by this template.
hidden and js part : would be in $data['form_beginning'] (or two variables for form and js)
tabs : a separate template for each tab and one global (but let's skip this part for now)
templates : should be a separate template for each operation (add /change / list / ....)
so templates would work just with several variables (ACPDV) :
- row associate array $row[field_name] plus $row_name and $row_help
- buttons array $button[save]
- beginning (form and js declaration)
- end (every beginning has to have an end :) )
L and F mode
- array of $rows
- header and filter
- buttons, beginning, end
plus some aditional info (current filter, page number, time, ...)
a feature i _really_ want is to have one pme table in L operation inside another in V operation. the L form has a filter depending on value in the V form (an invoice with several rows).
how do you think this could be achieved ? |
|
|
|
hbernard
|
|
2004-01-29 21:55
|
|
|
about the last sentence (subform) : this would be easily done but we need to tackle the #158. |
|
|
|
hbernard
|
|
2004-01-30 12:20
|
|
I don't know if you would consider me as phpMyEdit specialist, but here is my opinion ;-)
1/ Scope of this bug report :
"allowing custom layout for pme Add/change/view/delete/copy forms"
(keep out list/filter mode for now)
And keep out buttons order/display and so on....
2/
Whatever way you choose to achieve this, you're going to break the ability to easily maintain phpMyEdit forms (when you use this feature).
And also, this will not be so easy to play with 'tab' feature AND custom templates.
3/ michal 2004-01-28 11:20 idea (filling array in place of echoing html) :
nice because we start to separate content and layout
But
- you have to define ** lots of ** key names.
If you try to implement this, stick with css class names, if possible, please.
- too much work for someone who just want to have two fields on the same line in place of having them on successive rows.
- for pme technicals user (you, me) this not really easier than making an extension (see below)
4/ fred 2004-01-02 16:09 idea : dynamic template (and following bugnotes)
I agree with your first step: changing the current functions
Mainly because it will
- make code easier to read and to maintain
- make life of extensions maintainer easier.
Once that's done, then we will
- either add the 'template' suport
- or let it as is.
5/ Extensions vs templates
Currently, display_*_record are about 140 lines.
If you really want to customize a specific form, it's not that hard to make an extension that will override theses funcs.
And once we have smaller and separate display_*_records funcs, it will be easy.
6/ Current phpMyEdit "way"
If you look at the tab feature, you'll see that it's implementation is a very simple API for a very simple but powerful purpose.
Some technicals users (me...) just need ability to have multiple fields on the same form'row. (and I think this is the main idea behind your request).
A quick API for this could be
$opts['fdd']['myfield']['newrow'] = false;
Which say 'put it on the same line that previous field.
Maybe another bug report.
7/ and finally, a long term purpose should be to be able to use css absolute and relative positionning for templates (so content and layout are really separate things)
edited on: 2004-01-30 12:21 |
|
|
|
|
what about design like this:
function initialize()
{
switch($OP) ...initialising specific statements
// SQL reading, CSS initialising,...)
return "what needed"; // no echo in whole function
}
function end() {
switch($OP) ... ending statements if needed
return "what needed"; // no echo in whole function
}
function display_record() {
initialize();
if ( template ) // new customisable form
{
switch($OP) ... include (the right) template.php
// template.php only call generate_xxx() functions
for $k ...generate needed hidden fields
//for not yet generated fields
}
else for $k // normal part
{
echo <tr><td>name</td>
echo <td>
display_field($k)
echo </td>
echo <td>help</td></tr>
}
end();
}
that will make life of extensions maintainers even easier, won't it ?
my humble opinion is:
in phpMyEdit.class there should be _no_ echo
current pme behaviour (displaying standard output) should be done by an extention (a very simple, i guess).
the core class would be backend and extentions frontends.
i think we (kind of) agree on this (content and layout to be separate).
[it's two hours past midnight so i'm sorry if my thoughts are ... , but i'm out skiing whole next week, so i wanted to write my thoughts] |
|
|
|
hbernard
|
|
2004-02-02 11:05
|
|
[NB : Please read #172 and #173 before answering to this]
You may of course disagree, but then nepto has to tell us what he wants.
0/ Separating layout and content is a good thing ;-) but there are different ways.
And, echoing HTML4 is default behavior of PME and should stay in the main class.
1/ I disagree with having a whole array of pme outputs.
- Mainly because you can't imagine the level of precision you will need in the future (say now just separate button's bar, fields input, etc..., and maybe in the future : full control on how input field are echoed, etc...)
- I don't want to write yet another html-dialect
- you have to document this (unlike css feature, this is not a self-documented one)
- you will slow down whole phpMyEdit for only a tiny subset of technicals users.
- at the end, you will achieve exactly the same than parsing valid XML output (see below (4) and #172)
2/ Whatever way we choose, having smaller functions make allways life maintainer easier. This is the topic of this bug report, and this steps is requieed _BEFORE_ implementing templates.
3/ See #173 of why/how most of custom layout could be done via CSS. Read about CSS before answering (I know this will not allways be a good solution, but often it will). Please, comment in #173.
4/ Even with echoing in the whole pme class, it is possible to retrieve this output before displaying every thing you want. Read about php output buffering and xml_parse_into_struct func. I will upload sample in #172. Please comment in #172.
5/ Conclusion : First step : having small display_*_records funcs. |
|
|
|
|
1. that's true, precission will change in future. also this array can be easily achieved if we have many well designed small functions.
2. 5. small functions: i agree, some functions are a big mess (mainly list_table() ), which must be divided into smaller ones. so the discussion should be how this small function should be designed and what they should do. a separate bug report or discussion here ?
3. yes, i've heard about it. i will study this deeper.
4. ok |
|