I would like to add an attribute to some form elements in the action controller, I can do it like this:
$form->element_name->setAttrib('description', 'Anchor');
However in the above example the second argument gets escaped. I would like to have it unescaped. How can I do that?
You can use $decorator->setEscape(false); on Description decorator. Retieve it like $descriptionDEcorator = $element->getDecorator('Description');
You may have to experiment a bit but typically
$element->setAttrib("escape", false);
should work. I'm using it to not escape the content in a Zend_Form_Element_MultiCheckbox subclass right now. There's a setEscape method in the Decorator abstract that I believe this flags but the documentation isn't clear (as made obvious by the "enhancement" request).
Related
We need to change every <anything>/show routes to something localized.
How can we customize the show string in something like dettagli ?
You can do in two way:
By creating a custom operation, starting from the default Show operation. Copy-paste the code of the ShowOperation.php in your project, and change the route. Then throughout your project use your ShowOperation, instead of the one provided by Backpack.
By overriding the protected function setupShowRoutes($segment, $routeName, $controller) in your CrudController. If you have that method in your ProductCrudController for example, your method will be run instead of the one in the ShowOperation trait. However, this needs to be done in all CrudControllers individually, so it's less DRY.
Is it possible to use a variable inside the error message referring to the label of the form element? It's possible to map custom variables like %hostname% (in email validator) and the %value% is also available, but I'd like to have the form label as well.
I could't find it in the ZF codebase, but the use case is for example that the Zend_Validate_NotEmpty can return a message like:
"The field %label% is required and can't be empty"
Instead of:
"Value is required and can't be empty"
I think it's not possible without subclassing the validators. The Zend_Validate classes are not intended to be used with Zend_Form_Element only. Having a %label% in the message would introduce a coupling between both components.
A possible solution could be to create custom validators by extending Zend_Validate_NotEmpty (or whatever validators you are using) and pass the label to the constructor. This way, you could compose the appropriate message every time you instantiate it.
EDIT:
If you follow the method above, you could even define your own %label% "magic variable" and attach it to a member of the class. See the $_messageVariables member in the Example #2 in the Zend Framework documentation: Writing validators
Hope that helps...
I finally went with the decorator. The solution of dinopmi is possible, however you need to inject the label all the times. My error decorator for the form element replaces now the %label% to the real label.
i'm trying to dynamically add the class attribute to the body tag, and i came across this class. but i can't seem to understand how to use this class. i have something like this in my page class (or panel class, as i tried with that too):
add(new BodyTagAttributeModifier("class", "homepage", this));
this doesn't even compile, saying there's something wrong with the 2nd parameter. but i think String is automatically considered a Model in wicket, like the Label class. am i missing something here?
What if you just add an wicket:id to the body attribute and use the AttributeAppender class? Or, if the body attribute already has an id, can't you just use this class?
http://wicket.sourceforge.net/apidocs/wicket/behavior/AttributeAppender.html
Some Wicket Components have this String-to-model-shortcut (like Label), but it's not a general feature. You have to convert your String into a Model manually:
add(new BodyTagAttributeModifier("class", Model.of("homepage"), this));
I couldn't find any reference on how to use a parent form element in a subclassed form. May be because it's obvious to everyone but me. It's got me stumped. This is what I tried.
At first, within my form constructor I called
parent::__construct($options = null);
then accessed the parent elements like this
$type = parent::setName($this->type);
The problem was that ALL the parent form elements would display whether explicitly called or not. Someone said, "don't use __construct(), use the init() function instead. So I changed the constructor to init(), commented out the parent constructor, then ran the form. It bombed saying it couldn't pass an empty value for setName(). I commented out all the seName() calls and the form ran, but only displayed the elements instantiated in the subclassed form.
My question is this: If I don't use the parent constructor, how do i get and use the parent's form elements?
Solved: Since the constructor was switched to init, the call to the parent also needed to be switched. Easy for someone with php background. Not so much for one who doesn't.
Use
parent::init();
Solved: Since the constructor was switched to init, the call to the parent also needed to be switched. Easy for someone with php background. Not so much for one who doesn't.
Use
parent::init();
You should learn OOP principles first. Obviously you have no understanding of it whatsoever. You need to call parent::init() in you Form_Class::init() method as you wrote, but why? Because otherwise the parent method is not called and is overriden by the From_Class method.
Other thing is that when you have a parent class "SuperForm" with input and submit, then your "SuperForm_Subclass" would have the same elements assigned. There is no need to use "parent::*" to access element (only exception would be if you used static SuperForm variable to store them - which makes no sense).
You can easily use $this->inputElement and $this->submitElement inside your SuperForm_Subclass like you would in the SuperForm class.
In your example you could used the __contruct() as good, but with the same condition of calling the parent constructor. You would be able to access elements generated there too...
I'm using Moose and I need to wrap method calls in my project. It's important that my wrapping code be the most outer modifier. What I've done so far is put my method modifiers in a Moose Role and then applied that role at the end of my class like this:
use Moose::Util;
Moose::Util::apply_all_roles(__PACKAGE__->meta, ('App:Roles::CustomRole'));
__PACKAGE__->meta->make_immutable;
This allows me to be reasonably sure that my my role's modifiers are defined last, therefore giving me the correct behavior for "before" and "after." (The "before" and "after" in the role are called very first and very last.)
I originally thought this would be sufficient, but I now really need to wrap methods in a similar way with "around." Class::MOP, which Moose is built on, applies "around" modifiers very first, therefore they're called after "before" and before "after."
For more detail, here is the current calling order of my modifiers:
CUSTOM ROLE before
before 2
before 1
CUSTOM ROLE around
around
method
around
CUSTOM ROLE around
after 1
after 2
CUSTOM ROLE AFTER
I really need something like this:
CUSTOM ROLE before
CUSTOM ROLE around
before 2
before 1
around
method
around
after 1
after 2
CUSTOM ROLE around
CUSTOM ROLE AFTER
Any ideas on how to get my "around" modifier to be applied / called where I want it to? I know I could do some symbol table hacking (like Class::MOP is already doing) but I'd really rather not.
Simplest solution is to have CUSTOM ROLE define a method that calls the main method and then wrap that.
role MyRole {
required 'wrapped_method';
method custom_role_base_wrapper { $self->wrapped_method(#_) }
around custom_role_base_wrapper { ... }
before custom_role_base_wrapper { ... }
}
The problem you're having is that you're trying to have the CUSTOM ROLE around wrap something other than a method. Which is not what it is designed to do. Other than writing similar symbol table hackery like you've suggested (probably you could argue one of the Moose people into exposing an API in Class::MOP to help get there), the only other solution I can think of is the one above.
If you don't want the extra call stack frame that custom_role_base_wrapper will add, you should look at Yuval's Sub::Call::Tail or using goto to manipulate the call stack.
I'm fairly new to Moose, but why do you do this:
use Moose::Util;
Moose::Util::apply_all_roles(__PACKAGE__->meta, ('App:Roles::CustomRole'));
rather than simply this?
with 'App:Roles::CustomRole';
Regarding your question, it's a bit of a hack, but could you split your around method into before and after methods and apply the role at the end of your class definition (so it is applied in your desired order)? You could use private attributes to save state between the two methods if absolutely necessary.