michal
Joined: 17 Jun 2003
Posts: 537
Location: Slovakia
Posted: 2004-04-21 15:50
Back to top
Reply with quote
|
current dipslaying of VACPD pages is done in several different places with a lot of code duplication.
i am proposing some new functions:
- fieldDisplay($k)
it would return value or <input ..>, <select ...> as appropriate (according to settings and page type).
advantages:
easier implementation of proposed S mode and new extentions
reducal of code size (display_*_record can be merged)
already partially implemented
- prepare_display()
which would make sql query in VCD, read defaults in A, something in P, and nothing in S.
advantages:
real possibility to merge display_*_record into one
easier for extentions...
|
ajh
Joined: 17 Dec 2003
Posts: 236
Posted: 2004-04-22 08:35
Back to top
Reply with quote
|
Michal, I've been thinking about this too. It seems to me that the problem is that PME isn't really object oriented. It is written in a class which makes it easy to override functions for extensions, but otherwise it is written as a traditional program.
What I would like to see is the fields created as seperate objects, with attributes such as name, description, value, fieldtype, and all of the other PME attributes. You would have methods that get and set all of these things, as well as displaying the field. You would then pass an array of objects around PME rather than the array of arrays that we do today.
So to display a field you might do something like:
$fdd['f1']->disp_name()
$fdd['f1']->disp_value()
$fdd['f1']->disp_help()
The code to calculate the HTML is then in the class. Each field type would have it's own version of the class (with the same interface to PME) - so it would be very easy to extend PME to have other field types. You would just create another version of the field class with the same interface, but different code inside.
This also has another advantage...templating. If you didn't want to use the standard layout of fields on the screen, you could substitute the currently generate HTML for the table area with an included template which can reference the fields. Something like:
<TR>
<TD><?php $fdd['f1']->disp_name()></TD>
<TD><?php $fdd['f1']->disp_value()></TD>
<TD><?php $fdd['f1']->disp_help()></TD>
</TR>
etc.
What do you think?
|
hbernard
Joined: 23 Mar 2003
Posts: 159
Location: FRANCE
Posted: 2004-04-22 08:54
Back to top
Reply with quote
|
About an OO PhpMyEdit
Maybe i'm a conservative developper, but :
1. Yes, this would make the code in the class much more readable.
2. I'm not sure this would reduce a lot the amount of code.
3. This involve an API/FEATURE/BUG FREEZE for at least 3/6 months
4. And finally, with current php4 OO code, this would make PME much more slower. (One object instance per field, for example)...
5. This is equivalent to a rewrite from scratch.
I'm not really againt this proposition, but points above are important ones.
_________________
hbernard - phpMyEdit updater.
|
ajh
Joined: 17 Dec 2003
Posts: 236
Posted: 2004-04-22 09:24
Back to top
Reply with quote
|
Yes - I think that you have some fair points...
Possible there's a halfway point which uses OO for the field types, but keeps the fields themselves as an array.
So you would probably have the following class types:
"text", "password", "textarea", "select", etc all extending a basic fieldType class which has the basic functions that all of the field types use. The main class could also handle all of the basic parameters that occur in all field types (like "name", "help", etc etc). Maybe you would change the API to use a "field_type" (which has already been suggested) which just tells PME which field class to use.
To create new field types you then just extend the existing ones or the base field type depending on functionality. You could then just specify the new class names as your "field_type" attribute.
If we did this, a "calendar" field would just extend "text" and an "htmlarea" would extend a "textarea".
The main logic of PME would then simply have three wrapper functions: displayName, displayValue, displayHelp which would work out the type of the field and call the appropriate method of the appropriate field type object.
This approach avoids handling arrays of objects as you have just one class per object type.
|
michal
Joined: 17 Jun 2003
Posts: 537
Location: Slovakia
Posted: 2004-04-23 14:40
Back to top
Reply with quote
|
i was not aiming at creating new classes, my goal is just to tidy up the code.
fieldDisplay() would just distinguish which function is to be called, and call it. it would call display_*_field (which would return just value, no td-s). for a new input field, you would have to change only fieldDisplay() to tell when it should be called and add new display_some_field.
basic implementation can be done with some cut/paste (well a lot). but we would not have distinct display_*_fields, just a few very general (diplay_change_field for APC, display_delete_field for V, display_password_field).
general dipslay_record() would just call prepare_display() (which would get default values), dipslay table and tabs headers, and use fieldDisplay to display values (also names and help and a lot of td-s).
but this would be a huge but easy patch. so i'm worried....
ajh: you could be able to make
<TD><?php echo $MyForm->fieldDisplay('name_of_field'); ?></TD>
(or whatever the name would be - value_disp, cellDisplay, ...)
name is quite easy to implement (see custom header feature request)
help even easier :)
general questions that come into my mind:
1. use return or echo ? for some reasons, i prefer return (had a page with a lot of echos and had to rewrite most of it for a tiny new feature...)
2. display_*_field($name, $value) or display_*_field($name) so with two or just one argument. $value could be reached through a global variable. so i preffer just $name.
|
michal
Joined: 17 Jun 2003
Posts: 537
Location: Slovakia
Posted: 2004-04-27 12:01
Back to top
Reply with quote
|
see uploaded patch at http://opensource.platon.sk/projects/bug_view_advanced_page.php?f_bug_id=241
|
polman
Joined: 29 Aug 2025
Posts: 33
Posted: 2025-09-30 18:01
Back to top
Reply with quote
|
Essence is the leading online shopping store for shoes and accessories for women in Pakistan. Check out our fantastic collection of [block heels Pakistan](https://www.behance.net/gallery/235152353/From-Traditional-Chappals-to-Modern-Block-Heels?share=1) to get you ready for the weekend, or add some sparkle to your unique occasion wardrobe by browsing through our collection of party heels!
|
|
Post new topic
Reply to topic
|
Login
Registration
Slovak
