Module compatibility/interoperability problem

[Eric Schaefer]

Hi List,

the scheduler module uses date_popup for letting the user choose date
and time for scheduled publishing of nodes, if it is installed. This
causes a problem with the multistep module. With this module you can
divide the node form into multiple steps like a "node wizard".
date_popup transforms its two fields (date and time) into one field
during validation (?) since the date_popup widget is virtually one
field. If the scheduler field group is not part of the first multistep
step then there has not been any validation for the
scheduler/date_popup fields and therefore the publish_on field is
still an array of two (empty) values instead of a single value. This
confuses the schedulers validation logic, because it expects either an
empty string or a propperly formatted string but not an array. To fix
this I could check if it is an array and let it pass on validation.
That would be rather easy and straitforward. But I do not like the
idea of littering scheduler with code that circumvents problems with a
non-core module that is not even used by scheduler itself. This would
also introduce a nasty dependency on multisteps (form handling)
behaviour. That would be fine, if scheduler did actually use multistep
functionality (as it is using date_popups functionality), but it does
not. I do not like that and I don't think this is a good thing to do.

What do you think. What should I do? How can this problem be resolved
in a nice and clean way?

Regards,
Eric

[Brian Vuyk-2]

First things first, have you created issues in the issue queues for
these two modules? Chances are, the module maintainers will never see
this post.

Brian

Eric Schaefer wrote:

> Hi List,
>
> the scheduler module uses date_popup for letting the user choose date
> and time for scheduled publishing of nodes, if it is installed. This
> causes a problem with the multistep module. With this module you can
> divide the node form into multiple steps like a "node wizard".
> date_popup transforms its two fields (date and time) into one field
> during validation (?) since the date_popup widget is virtually one
> field. If the scheduler field group is not part of the first multistep
> step then there has not been any validation for the
> scheduler/date_popup fields and therefore the publish_on field is
> still an array of two (empty) values instead of a single value. This
> confuses the schedulers validation logic, because it expects either an
> empty string or a propperly formatted string but not an array. To fix
> this I could check if it is an array and let it pass on validation.
> That would be rather easy and straitforward. But I do not like the
> idea of littering scheduler with code that circumvents problems with a
> non-core module that is not even used by scheduler itself. This would
> also introduce a nasty dependency on multisteps (form handling)
> behaviour. That would be fine, if scheduler did actually use multistep
> functionality (as it is using date_popups functionality), but it does
> not. I do not like that and I don't think this is a good thing to do.
>
> What do you think. What should I do? How can this problem be resolved
> in a nice and clean way?
>
> Regards,
> Eric
>  

[Eric Schaefer]

2009/10/16 Brian Vuyk <brian@...>:
> First things first, have you created issues in the issue queues for these
> two modules? Chances are, the module maintainers will never see this post.

Well I could but it is actually a strange situation. It is neither
Multisteps, nor Date Popups nor Schedulers fault. Nobody is doing
something wrong. The reason for this problem is that all three modules
need to do something "smart". Date Popup pretends its only one field
while its actually two, Multistep manipulates the form handling and
Scheduler assumes there is only one field. Either module could do
something to prevent the problem but not without "knowing" about the
other modules. Scheduler could check if the field contains a string or
an array (which would be the easiest fix). But if Date Popup changes
the implementation that is normally hidden behind the virtual single
field or if Multistep does something different to hide fields that are
not part of the current step, scheduler would have to change too. That
would be pretty ugly.

I am asking this question in the mailing list, because I know you are
alle much smarter than I am and maybe someone know how to escape the
dilemma.

Regards,
Eric