[Agavi-Tickets] [Agavi] #1199: AgaviValidator sets dependencies per argument base
Agavi
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: dominik
Type: enhancement | Status: new
Priority: normal | Milestone: 1.0.2
Component: validation | Version: 1.0.1
Severity: normal | Keywords: validator dependency
Has_patch: 0 |
-----------------------------------------+----------------------------------
Hi guys,
recently I ran into the fact, that validator dependencies are set only for
the current argument base.
I would see a real big enhancement if these were set independent from the
current base, e.g. to provide dependencies from a settings parameter and
to set up validation for a data base depending on the settings.
My use case here is a "container" parameter where I place the is_slot
parameter to set up validation depending on whether I have slot or normal
action mode.
--
Ticket URL: <http://trac.agavi.org/ticket/1199>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
tic...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/tickets
Agavi
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: dominik
Type: enhancement | Status: new
Severity: normal | Keywords: validator dependency
Has_patch: 0 |
-----------------------------------------+----------------------------------
* milestone: 1.0.2 => 1.0.3
Comment:
Moving to 1.0.3, but I think this is actually more of a 1.1 feature.
Could you clarify this a bit further maybe, with code samples and expected
behavior?
--
Ticket URL: <http://trac.agavi.org/ticket/1199#comment:1>
Agavi
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: dominik
Type: enhancement | Status: new
Severity: normal | Keywords: validator dependency
Has_patch: 0 |
-----------------------------------------+----------------------------------
Comment(by sven.kretschmann@…):
Hi David,
here are the code samples. I posted both versions of the validation
configuration (one working without using a base and one using a base).
Affected files:
* SearchAction (search in normal mode, more simple in slot mode
* SearchInputView (display the input field and settings for the search)
* SearchSlotView (display only the input field in the marginal column)
* SearchSuccessView (display the search results)
* Search.xml (validation config)
SearchAction:
{{{
public function registerValidators()
{
$container_parameters = array(
'is_slot' =>
(bool)$this->getContainer()->getParameter('is_slot', false)
);
$this->getContainer()->getRequestData()->setParameter('__container',
$container_parameters);
}
}}}
Search.xml (current, working, without base)
{{{
<validator class="equals" required="false"
provides="container.is_no_slot">
<arguments>
<argument>__container[is_slot]</argument>
</arguments>
<errors>
<error>Invalid is_slot part given.</error>
</errors>
<ae:parameters>
<ae:parameter name="severity">silent</ae:parameter>
<ae:parameter name="value">false</ae:parameter>
</ae:parameters>
</validator>
<validator class="equals" required="false" provides="container.is_slot">
<arguments>
<argument>__container[is_slot]</argument>
</arguments>
<errors>
<error>Invalid is_slot part given.</error>
</errors>
<ae:parameters>
<ae:parameter name="severity">silent</ae:parameter>
<ae:parameter name="value">true</ae:parameter>
</ae:parameters>
</validator>
<validator class="number" name="invalid_limit" required="false"
depends="container.is_no_slot">
<arguments>
<argument>limit</argument>
</arguments>
<errors>
<error for="min">The limit must be a positive integer.</error>
<error for="type">The limit must be numeric.</error>
</errors>
<ae:parameters>
<ae:parameter name="min">1</ae:parameter>
<ae:parameter name="type">integer</ae:parameter>
</ae:parameters>
</validator>
}}}
Search.xml (enhanced, does not work)
{{{
<validator class="equals" required="false"
provides="container.is_no_slot">
<arguments base="__container">
<argument>is_slot</argument>
</arguments>
<errors>
<error>Invalid is_slot part given.</error>
</errors>
<ae:parameters>
<ae:parameter name="severity">silent</ae:parameter>
<ae:parameter name="value">false</ae:parameter>
</ae:parameters>
</validator>
<validator class="equals" required="false" provides="container.is_slot">
<arguments base="__container">
<argument>is_slot</argument>
</arguments>
<errors>
<error>Invalid is_slot part given.</error>
</errors>
<ae:parameters>
<ae:parameter name="severity">silent</ae:parameter>
<ae:parameter name="value">true</ae:parameter>
</ae:parameters>
</validator>
<validator class="number" name="invalid_limit" required="false"
depends="container.is_no_slot">
<arguments>
<argument>limit</argument>
</arguments>
<errors>
<error for="min">The limit must be a positive integer.</error>
<error for="type">The limit must be numeric.</error>
</errors>
<ae:parameters>
<ae:parameter name="min">1</ae:parameter>
<ae:parameter name="type">integer</ae:parameter>
</ae:parameters>
</validator>
}}}
--
Ticket URL: <http://trac.agavi.org/ticket/1199#comment:2>
Agavi
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: dominik
Type: enhancement | Status: new
Severity: normal | Keywords: validator dependency
Has_patch: 0 |
-----------------------------------------+----------------------------------
* milestone: 1.0.3 => 1.1
Comment:
Sounds similar to the change we did to "export" where you can use
{{{sprintf()}}} syntax, except that this one would break BC quite a bit;
right now you can do:
{{{
#!xml
<validator … provides="fubar">
<arguments base="foo[]">
<argument>bar</argument>
</arguments>
</validator>
<validator … depends="[fubar]">
<arguments base="foo[]">
<argument>baz</argument>
</arguments>
</validator>
}}}
which is, arguably, ugly and/or broken, and not what one would expect.
An {{{sprintf}}} syntax would allow for a lot more flexibility, including
depending on "provide"s in other argument bases, but that needs some
thought and speccing.
Moving to 1.1.
--
Ticket URL: <http://trac.agavi.org/ticket/1199#comment:3>
Agavi
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: dominik
Type: enhancement | Status: new
Severity: normal | Keywords: validator dependency
Has_patch: 0 |
-----------------------------------------+----------------------------------
Comment(by david):
#1320 is a duplicate of this ticket.
--
Ticket URL: <http://trac.agavi.org/ticket/1199#comment:4>
Agavi
argument base parts
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: david
Type: enhancement | Status: closed
Priority: normal | Milestone: 1.1
Component: validation | Version: 1.0.1
Severity: normal | Resolution: fixed
-----------------------------------------+----------------------------------
* status: assigned => closed
* resolution: => fixed
Comment:
(In [4883]) Support arbitrary "provides" and "depends" validator options
with access to argument base parts, closes #1199
--
Ticket URL: <http://trac.agavi.org/ticket/1199#comment:6>
Agavi
argument base parts
-----------------------------------------+----------------------------------
Reporter: sven.kretschmann@… | Owner: david
Priority: normal | Milestone: 1.1
Severity: normal | Keywords: validator dependency
Has_patch: 0 |
-----------------------------------------+----------------------------------
* owner: dominik => david
* status: new => assigned
Comment:
So the idea then is:
{{{
#!xml
<validator … provides="fubar">
<arguments base="foo[]">
<argument>bar</argument>
</arguments>
</validator>
}}}
would now set just {{{fubar}}} for every iteration in {{{foo[]}}},
contrary to the old behavior which set {{{foo[$key][fubar]}}} (the
argument base is used in the string, but the argument itself is not
included).
On the other hand,
{{{
#!xml
<validator … depends="fubar">
<arguments base="foo[]">
<argument>bar</argument>
</arguments>
</validator>
}}}
would still, like in 1.0, depend on just {{{fubar}}} (you'd have to use
{{{[fubar]}}} to depend on {{{foo[$key][fubar]}}}, and that shows the
problem nicely - you can only depend on "provides" set in the same
argument base).
The old behavior is automatically kept for 1.0 config namespaces, but if
you want it for 1.1 namespaces, then in the above example you'd have to do
{{{
#!xml
<validator … provides="foo[%2$s][fubar]">
<arguments base="foo[]">
<argument>bar</argument>
</arguments>
</validator>
}}}
and
{{{
#!xml
<validator … depends="foo[%2$s][fubar]">
<arguments base="foo[]">
<argument>bar</argument>
</arguments>
</validator>
}}}
Since the {{{sprintf()}}} expansion works on all argument base parts, just
like for {{{export}}} (see #1073), you could in both cases also use
{{{%1$s[%2$s][fubar]}}}, since "foo" is the first part of the argument
base and the dynamic key (inside the square brackets) is the second part.
Of course, you don't even have to go this far for such a simple example;
{{{foobarset[%2$s]}}} is sufficient in both cases if you only care about
the dynamic key part in square brackets.
--
Ticket URL: <http://trac.agavi.org/ticket/1199#comment:5>