Phalcon\Html\TagFactory setDefaults() method?

[richmilns]

I am currently upgrading from v4 to v5 and one issue I have run into is that Phalcon\Html\TagFactory does not seem to have a setDefault() or setDefaults() method.

In the v5 docs, it says "NOTE Phalcon\Tag will be removed in a future Phalcon version. The functionality is offered by the Phalcon\Html\TagFactory component."

So in my v4 app bootstrap, where I set the tag service I used to do:

$di->setShared('tag', new \Phalcon\Tag());

My v5 app bootstrap looks like this:

$di->setShared('tag', new \Phalcon\Html\TagFactory(new \Phalcon\Html\Escaper()));

Does anyone know how to call the setDefaults() method (or the v5 equivalent) if using Phalcon\Html\TagFactory instead of Phalcon\Tag ?

[s-ohnishi]

I also have the same problem.
It would be very troublesome if the problem could not be solved and stopped, so I think that either specifying the entity in the Forms constructor or bind (), or setting the view property and reading it in the template.

[richmilns]

I think the problem is quite a bit deeper than I had hoped. My plan was to extend the Phalcon\Html\TagFactory class, add the missing methods for setDefault(s) and then in the __call method of my new class I was going to check and set a default value in the arguments, if a value array key had not been set:

e.g. {{ text_field('test_field') }} which would use a default value if specified instead of {{ text_field(['test_field', 'value': 'test']) }} which already sets the value in the view code.

In my app, I was already using a customised extended class based on Phalcon\Tag which wasn't an issue before because it my class replaced the original Phalcon\Tag class in the DI (this was done in my app bootstrap).

Unfortunately, when using Volt for rendering views, Phalcon\Mvc\View\Engine\Volt\Compiler now directly reference the Phalcon\Tag before it checks the DI for the new TagFactory service.

In V4, Phalcon's Volt complier class functionCall method would be using the tag service instead of calling the Phalcon\Tag class directly for things like text_field: see here (v4) and here (v5).

Right now, I'm thinking that if you are not using a Form class then basically the best thing to do is to refactor any code that used setDefaults() previously, and as @s-ohnishi suggested set variables in your view that you can then use as the value for form fields generated by TagFactory in v5.

I'm thinking of raising this as an issue, but I'll ping the Discord channel for advice first.

[niden]

Humor me guys. I know setDefaults for Tag sets some default values for fields that come up later on in our code.

Why would one want this? (full disclosure I have never used this in a project).

As for the implementation, the problem we had with Tag (and still exists) is access and manipulation of the globals, that was the main reason this was not implemented in the TagFactory.

The implementation will require a change to the interface of AbstractHelper to accept the TagFactory object (link them together) and then in the TagFactory one can set defaults there. If they match for any element then that default will be used. We could also make some sort of "smart" structure where name1 becomes the default only for Text helpers while name2 becomes the default for all helpers. We can set up some sort of array structure to incorporate that flexibility.

I do not want us to use superglobals for setDefaults, I would rather have an array passed to the TagFactory

Thoughts?

[richmilns]

I do not want us to use superglobals for setDefaults, I would rather have an array passed to the TagFactory

Completely agree with this.

So I think from my side, it's two things: the first is to make it as easy as possible to get people onto v5+, so as much backwards compatibility as possible is always a good thing!

The second thing is that this feature does actually help to reduce the amount of code you need to write in my opinion, if you are not using Form classes. Example use case: a small filter form, with one or two filters (perhaps e.g. keywords and status). This is perhaps pushing the use case for a separate form class, and therefore it is convenient to be able to set the default values for fields created by the Volt form helper methods in your controller instead by calling setDefaults() . It also helps to keep your Volt code cleaner in my opinion, as otherwise you would need to interact with the request service for example to get the default values.

I suppose in reality it's a small job to refactor existing code to use variables set in the view rather than calling setDefaults() as suggested by @s-ohnishi however I think the docs could be improved if this is the new recommended implementation?

I think probably the bigger issue for me is that the references to Phalcon\Tag are now hard coded in the Volt Compiler class - this means that my app's extension of Tag, which makes generated HTML more compatible with Bootstrap front end code, is no longer used when I call the Volt helper methods such as {{ text_field() }} etc

[niden]

Indeed Tag is hard coded in the volt compiler but it is only used if you use the relevant methods, as you mentioned text_field().

As for the defaults, I went and looked again the code and it is really a static array that holds the name of the field and its value.

For a getValue() on the element, the code first checks the value attribute, then the defaults array and then the $_POST. This is not a difficult code to replicate and incorporate in the TagFactory. The key would be to "link" the TagFactory and its subelements so that those elements know what the default value is at any given point, should the value is not set.

So the issue becomes how to make those elements aware of their default values, since they are subclasses so to speak.

Let's take the inputText for instance.

echo $this->tag->inputText('test-name', 'test-value', [ 'id' => 'my-id' ] );
// <input type="text" value="test-value" id="my-id" >

With Volt:

{{ tag.inputText( 'test-name', 'test-value', [ 'id' : 'my-id' ] }}

If we leave the value empty, then the element will not have a value. However, we need some sort of mechanism to set a default, if this value is empty.

This is one option.

echo $this->tag->setDefault('blah')->inputText('test-name', '', [ 'id' => 'my-id' ] );
// <input type="text" value="blah" id="my-id" >

With Volt:

{{ tag.setDefault('blah').inputText( 'test-name', '', [ 'id' : 'my-id' ] }}

It does however create a maintenance nightmare.

I am leaning towards this:

$defaultValues = [
    'test-name' => 'blah',
];

$this->tag->setDefaults($defaultValues);

echo $this->tag->inputText('test-name', '', [ 'id' => 'my-id' ] );
// <input type="text" value="blah" id="my-id" >

Upon creation, the inputText element will receive the default value if specified in the $defaultValues array and then use it when it renders if necessary

The only thing I can think of that might throw things off is if a developer wants to change the default values mid request, at which point the element would not be aware of that change.

Thoughts?

[s-ohnishi]

I'm working on v5 support for the INVO application now, and it looks like it has the sample you're looking for.
For normal session/login access, the default email and password are set as value attribute values.
(I don't care if this is good UI)

In the new user registration process, blanks are set instead of the default values above and forwarded to session/login.
(Perhaps the author of this app wants to set the newly registered email and password instead of the default values)

[richmilns]

I like your approach for setting defaults as outlined above 👍 For my app, I'm migrating everything over to use Form classes where possible, but I do think that this could be a breaking change for people coming from v4 in certain situations.

I would like to add that it would be nice to have control over the Tag class used in the Volt compiler.

As mentioned above, this is hard-coded in v5 and it would be nice to be able to override this. e.g.

return "\Phalcon\Tag::" . method . "(" . arguments . ")";`

Becomes:

return this->getTagClass() . "::" . method . "(" . arguments . ")";

This has been done in other places in the framework for added flexibility.

That way it can be controlled if someone wants to extend the Compiler class? What do you think?

[s-ohnishi]

You can still use the old format, eg {{ link_to("companies/new", "Create Companies", "class": "btn btn-primary") }}.
(The new format is {{ tag.a(url('companies/new'), 'Create Companies', ['class':'btn btn-primary']) }})
So I don't think it's necessary to modify the Volt compiler.

v4 users are using methods like the above that are replaced by Phalcon\Tag::some() which can still be used, and no one is using {{ tag.some() }}, so there is a conflict I think it is possible to coexist without it, and to gradually change parts of it.
(However, the part that uses $this->tag->setDefault() in the controller needs to be modified, but I think it is good news that Phalcon\Tag::setDefault() can be used.)

With a high degree of flexibility, we can foresee a situation where the majority of people will not switch to TagFactory and overall migration will not progress.
Whether or not it has sufficient compatibility as a transition to v5 will differ depending on the person, but I think there is no problem with the current situation.