extending disco

[Steve]

Hi all,

It was great seeing/meeting everyone earlier this week.

I been trying to extend the textdatetime plasmature type. I am able to
do this in the core, but would rather do it locally. My problem is
that I guess I assumed wrongly that if I built out the directory
structure locally (reason_package_local/disco/plasmature/types/
textdatetime.php), then this would override textdatetime.php in the
same directory in core. How do I set this up?

Thanks,
Steve

[Nathan White]

Hi Steve - I second the "great seeing/meeting everyone." It was lots of fun and we'll have to plan another get together in the not too distant future. Thanks to all presenters - you were fabulous.

The reason_package/reason_4.0/lib/ directory within Reason is where the core / local split starts.

Disco can be used independently of Reason, and thus doesn't have the core / local split functionality that is built into the Reason code base.

If you can code it in such a way that its a drop in replacement, with added functionality, we could look at using it in the core instead of the existing type. It would have to be done in such a way as to be independent of Reason, however (you could still use constants in package_settings.php).

Call me if you want to chat further about it.

Nate

[Matt Ryan]

If you could be a little more specific about what you are looking for,
we could provide a clearer answer.

The key distinction is: do you want to replace the textdatetime
plasmature type everywhere it is used, or do you simply want to have
at your fingertips an alternate version that is an extension, and
could be names something different?

If you want to do the former, I'd have to think for a while to
determine the best way to do that. It might require some changes to
how disco works to do it nicely.

If the latter, the answer is actually quite easy, since there is no
requirement that plasmature elements be defined inside the disco
directory.

1. Put a php file somewhere (it can be in reason_package_local if you
want, but it's not critical) and do the following things:
2. Include the base plasmature file.
3. Create a class that extends textdatetime and override any behavior
or markup that you wish
4. Whenever you want to use this new plasmature type, just include it
at the top of the file where you will be adding the element to disco.

Matt

[sls]

> The key distinction is: do you want to replace the textdatetime
> plasmature type everywhere it is used, or do you simply want to have
> at your fingertips an alternate version that is an extension, and
> could be names something different?

Both I think. I'd like to do a couple of things.

1. I'd like to exclude the seconds textbox when we request a time on a
public facing form. But, the field is in use on the backend. I can't
imagine a situation in which we would need seconds from someone
filling out a front-end form. In the short term, I can use the
instructions you provided to remove the seconds textbox.

Can anyone else think of a situation in which you would want a user
entering seconds on a form? If not, I could look into adding it to the
core so that any form with a public face doesn't display the seconds.


2. I'd like to be able to pass class statements to the date picker to
use various options it offers (or perhaps the <a href="http://
jqueryui.com/">jqueryUI</a> datepicker, which we are leaning towards
using). I believe this would be useful to everyone. So, I will try to
add it to the core code.

[Matt Ryan]

A quick grep doesn't reveal any front-end forms in the core that use
the textdatetime plasmature type. Am I forgetting something?

Matt

[sls]

When I create an change an element to textdatetime type using a thor
view this is the result https://reasondev.luther.edu/x/individualvisit/.

From datetime.php, lines 154-166:
/**
* All datetime portions. This array in child classes define which
fields we want to capture.
* @var array
*/
var $use_fields = array(
'month',
'day',
'year',
'hour',
'minute',
'second',
'ampm',
);

and lines 341-358
function get_display()
{
$str = '';
foreach($this->use_fields as $field_name)
{
$get_val_method = 'get_'.$field_name.'_value_for_display';
if(method_exists($this, $get_val_method))
$display_val = $this->$get_val_method();
else
$display_val = $this->$field_name;
$display_method = 'get_'.$field_name.'_display';
if(method_exists($this, $display_method))
$str .= $this->$display_method($display_val);
else
trigger_error($field_name.' is in $use_fields, but no display
method exists for it');
}
return $str;
}

Thanks,
Steve

On Oct 9, 4:35 pm, Matt Ryan <matt.d.r...@gmail.com> wrote:
> A quick grep doesn't reveal any front-end forms in the core that use
> the textdatetime plasmature type. Am I forgetting something?
>
> Matt
>

[Matt Ryan]

Gotcha. What I would do is to follow slightly different practices when
coding up a front-end form (or a back-end form, if you don't care
about seconds).

Here is some pseudocode to explain what I mean:

my_plasmature_file.php:

include_once('paths.php');
include_once(DISCO_INC.'plasmature/plasmature.php');
class textDateTimeNoSecsType extends textDateTimeType {
var $use_fields = array('month','day','year','hour','minute','ampm');
}

In a disco form:

include_once('my_plasmature_file.php');
$this->change_element_type('element_name','textdatetimenosecs');

If you have a bunch of local front-end forms, it should be simple to
grep for textdatetime and replace with textdatetimenosecs. Once you've
got it working smoothly, contribute the type back and we can include
it in plasmature proper.

Matt