Does Zend Framework have a nl2br filter? I can't see it - am I just missing it?
I imagine I could do the same thing with PregReplace...
When we have an existing PHP function nl2br it really begs the question: "do we really need to wrap a ZF filter class around a function?"
There are a few filters that actually do that.
In terms of forms for injecting a filter (and maybe other cases) I would say yes or when we need some more flexibility with additional options; basically extending the PHP function. I don't really see a need for this particular function and you should be fine to simply use PHP out of the box.
No, Zend Framework dos't have nl2br filter. If you want to use it then you should put it in your code where you want.
You can use any other methods also similar to that for achieving this.
Related
Both are easy to use, both give the same output.
So what is the difference? Are there any advantages to use one or the other? Is there any advantage in performance, security or what ever?
Which one would I use better if I want to manipulate view during runtime?
If we talk on zend-view, both using render's view method then calls rendrChild method recursively. So we can say there's not performance difference.
Here's the zend-view's render method and here partial helper using it
I'd really like to use case classes' copy feature in my project, but unfortunately I also need inheritance, which doesn't work well with case classes. So, I'm wondering if it's possible to write a macro which will generate a method for creating copy-with-changes object for an arbitrary class. What stops me there at the moment is the fact that AFAIK macros don't support named parameters. Has anyone found a way around that or, alternatively, can suggest other way for easy creating of copies which use inheritance?
That will be possible with type macros and/or annotation macros. The current macros do not support this.
Do look at lenses work, though. There's quite a few macro-based versions around, such as Shapeless.
You could also take a look at https://github.com/dicarlo2/ScalaEquals
I have about 6 forms to design with UIBinder that look almost the same, the difference is two or three fields. I was thinking about building one form with all the possible fields and hide or show fields depending on the case.
What do you think about this method?
It can work well. You can define a BaseForm class with UiBinder that implements HasWidgets, and then define SpecificForm1.ui.xml with something like
<custom:BaseForm>
<g:TextBox ui:field="componentSpecificToThisForm" />
<g:Button>A button!</g:button>
</custom:BaseForm>
and SpecificForm2.ui.xml with something like
<custom:BaseForm>
<g:Label>Something totally different</g:Label>
<g:Button>A button!</g:button>
</custom:BaseForm>
it works great!
I've tried something similar, and building one form where I hid/show the appropriate fields was the most simple solution. Another idea would be create a factory, which then builds your form according to your needs.
So, you basically create the components your form is composed of, and the factory wires them together via constructor dependency injection. Worked very well for me, and also has the added benefit that it is very easy to extend your form.
(I'll add an example later).
I'm looking for an end to end example using dojo.store with dijit.Tree over REST.
There are many existing examples that use the older dojo api, dojo.data.api, but a dearth of ones using the dojo.store api.
Is the reason that dijit.Tree doesn't fully support dojo.store yet?
If so, do I need to use the dojo.data.ObjectStore wrapper to encapsulate dojo.store for use with dijit.tree?
I saw one example of working around this by extending StoreFileCache:
http://dojo-toolkit.33424.n3.nabble.com/New-object-store-and-dijit-Tree-td2680201.html
Is that the recommended option, or should I
a) stick to dojo.data.api until dijit.Tree supports dojo.store directly, or
b) use the dojo.data.ObjectStore wrapper
Thanks
There is now a tutorial on the DTK website that seems to cover pretty much exactly this topic.
http://staging.dojotoolkit.org/documentation/tutorials/1.6/store_driven_tree/
However, as I know linking to something without giving an answer is considered a poor practice, the general idea is that rather than using a dojo.data.ObjectStore to wrap around it and then potentially shoving it through a ForestStoreModel, you can simply augment your dojo.store-based store to add the methods that the Tree will look for. Here's a simple example from the tutorial:
usGov = new dojo.store.JsonRest({
target:"data/",
mayHaveChildren: function(object){
// see if it has a children property
return "children" in object;
},
getChildren: function(object, onComplete, onError){
// retrieve the full copy of the object
this.get(object.id).then(function(fullObject){
// copy to the original object so it has the children array as well.
object.children = fullObject.children;
// now that full object, we should have an array of children
onComplete(fullObject.children);
}, onError);
},
getRoot: function(onItem, onError){
// get the root object, we will do a get() and callback the result
this.get("root").then(onItem, onError);
},
getLabel: function(object){
// just get the name
return object.name;
}
});
It's worth noting that in this case, we're making some assumptions about what the data looks like. You'd need to know how your children relate and customize the methods below for that purpose, but it's hopefully fairly clear as to how to do that for yourself.
You can also just stick to dojo.data APIs for now, but this approach definitely feels more lightweight. It takes a couple of layers out of the stack and working with customizing a dojo.store-based store is much easier.
Given the two options you outlined, I'd say it's a matter of how well you know the different APIs.
dojo.store is more light-weight, and perhaps easier to understand, but the wrapper adds some overhead. If you think your project will live for a long time, this is probably the best way to go.
dojo.data is a legacy API, which will phased out eventually. If your project is short-lived, and only based on dijit.Tree, this might be your best option for now.
Personally, I'd go with dojo.store and write my own TreeStoreModel to get the best of both worlds. This approach is very similar to Brian's suggestion.
In case you're interested, I've written up a two-series post on how to use dijit.Tree with the ObjectStore wrapper, and implementing a JsonRest backend in PHP.
For a REST interface:
What is the best way to allow the client to set many equally named parameters in a GET?
For example if the client should specify multiple possible colors
www.example.com/products/{color=green|color=yellow|color=white| ...}
Something like this would be fine:
GET http://www.example.com/products?colors=green,yellow,white
Despite popular opinion, there is no REST constraint that says you should not use query string parameters.
Considering browsers consider the application/x-form-urlencoded and the querystring equivalent, and considering several values can be provided for the same name, you can simply do
color=red&color=green&color&blue.
Provided your framework of choice handles this correctly, this should be jsut fine.