text:
Thursday, February 20, 2014
Duck Fat Steak Fries – There's a New Fat in Town
15 comments:
- Julia said...
Boy oh boy!
Dips? Sauce? Mayonnaise? Ketchup? Sour cream? Yogurty type thingy? Something way,way better?
- February 20, 2014 at 7:01 PM
- Dan Bremer and Emily Schleicher said...
Would it be blasphemous to use lard?
- February 20, 2014 at 7:07 PM
- Chef John said...
Use what you have!
- February 20, 2014 at 7:12 PM
- Chef John said...
Julia, yes, all of the above!
- February 20, 2014 at 7:14 PM
- Beth said...
"Yes, definitely!" to duck fat! Any adjustments for sweet potatoes?
- February 20, 2014 at 8:03 PM
- Just Ming said...
Looks awesome! Gonna try making some.
- February 20, 2014 at 8:55 PM
- Vincent said...
As far as duck fat being healthy goes, it's about 60% unsaturated fat, which is pretty good compared to butter (something like 35% unsaturated fat?), but sticking to olive oil (85% sounds about right) is still the healthiest option.
...But who wants to be healthy if you're not allowed to eat boatloads of these gorgeous looking things?
- February 20, 2014 at 9:27 PM
- jhormuz said...
Hey Chef John, given the origins of the word "fry" (ie- to cook in oil), I'd say that 100% of the words in the title refer to fat or meat. :)
- February 20, 2014 at 11:45 PM
- philogaia said...
So funny to see this today. A friend posted a roasted cabbage slab recipe yesterday that sounded great except that it called for cooking spray. I commented I would rather try it with butter or even better, duck fat. Her response was butter sounded good but duck fat? Ewww. Poor woman. She just doesn't understand.
- February 21, 2014 at 11:38 AM
- Ed Adams said...
Big Fan Chef. I try not to ask questions here, but not seeing the potatoes rinsed to get rid of the extra starch I was just curios, did you omit that part of the video OR should the potatoes not be de-starched for this recipe? Thanks.
- February 21, 2014 at 12:22 PM
- Chef John said...
These seem to crust up beautifully whether you rinse or not!
- February 21, 2014 at 1:52 PM
- Monica said...
Have to look for that when next in the big city, San Antonio. Don't think it is used in Mexican cooking but there are enough yuppies in the city.
- February 21, 2014 at 2:17 PM
- will dukeshire said...
Yet another awesome thing! gonna try this the weekend. I also luv the fact that you use cayenne pepper so much, it is so healthy.
Thanks again for another awesome recipe. from your friend willy in newfoundland canada
- February 21, 2014 at 4:43 PM
- 49ersaredabest said...
Hi Chef John,
These look great.
If I cant find duck fat, would these work with just bacon fat?...
- June 8, 2014 at 10:04 PM
- Laura W Kline said...
We are using bacon fat. Although we might look for duck fat now that we know it's available. But we have bacon fat.
- September 16, 2014 at 7:21 PM


text:
Monday, December 22, 2014
Follow us:
Hudson Valley
Time Warner Cable video customers:Sign in with your TWC ID to access our video clips.
Sign in
To view our videos, you need to
install Adobe Flash 9 or above. Install now.
Then come back here and refresh the page.
HUDSON VALLEY, N.Y. – A heads up for victims of Superstorm Sandy looking for some government assistance. The deadline for requests for public assistance has been extended for another month.
Not-for-profit groups in Orange, Putnam, Sullivan and Ulster counties now have until February 11th to file all the necessary paperwork. Originally those groups had to have their requests in by Saturday.
Individuals looking for aid must submit their applications by January 28th.
For more information on how to file your requests, visit www.dhses.ny.gov.
Reproduction in whole or in part without permission is prohibited.
© 1999-2014 Time Warner Cable Enterprises LLC. All Rights Reserved.
Web design and web development by Tipit.

subset: commoncrawl


text:
Start learning with our library of video tutorials taught by experts. Get started
Introduces the Adobe web typography subscription service, showing how to embed and deploy a variety of font styles quickly and easily.
"I have yet to find a course that I didn't find useful, well organized, and informative. And it's always at my fingertips." —Leslie M.
more from our members »


text:
infolupki.pgi.gov.pl/en This unconventional oil and gas news service is a source of expert information on shale gas resources, exploration and production technology, as well as on environmental, social and economic aspects
GeoShale2014 Conference (September 24-26, 2014) was held in line with conclusions of its predecessor - GeoShale2012 Conference on Recent Advances in Geology of Fine-grained Sediments. It was organized by the Polish Geological Institute under the patronage of the Polish Ministries of Environment, Science and Higher Education, EuroGeoSurveys and IUGS and AAPG-Europe Office.
Polish Geological Institute – National Research Institute and the Minsk-based Belarusian Research Geologic Exploration Institute undertake further actions to implement joint monitoring of groundwater in border regions. An important step in the direction was the workshop organized in the PGI on 26-27 August 2014, which provided a forum for the exchange of experience in that field.
The Minister of Environment recalled Prof. Jerzy Nawrocki from the post of the director of the Polish Geological Institute – National Research Institute. Mr. Roman Smolka, the present Deputy Director, has been appointed to hold the office untilthe vacancy is filled.
PGI-NRI offerHydrocarbons from unconventional resources (shale gas and oil, tight gas, coal bed methane) (PDF 12.37 MB 2014-06-12)
Shale gas and oil News service of Polish Geological Survey
Mineral resources of Poland Data about 13,197 mineral deposits in Poland as of 31.12.2013
Map of landslides threatening the important objects in the Carpathiansshows the location of 61 landslides monitored by PGI-NRI
We use cookies on our site. Please see your browser settings to allow or disable them.


text:
Zend_View 2.0 Notes on development

Update to use PluginLoader

Currently, Zend_View uses its own system for managing plugins. This leads to issues when branching Zend_View, as well as to inconsistencies with the rest of the framework. It needs to be adapted to use Zend_Loader_PluginLoader for better consistency, to adhere to the DRY principle, and to allow for custom Plugin Loading solutions for helpers and filters.

Note: this is currently done in the incubator.

Allow optional use of streams to emulate short_open_tags on systems where it is disabled

Currently, there's some confusion regarding the use of short_open_tags with ZF.

Our coding standards dictate using full <?php tags at all times, but our

documentation utilizes short tags for view scripts.

The recommendation all along is that library code should utilize fully qualified

tags, but that view scripts can and should use short tags for brevity and

Unfortunately, current versions of PHP only allow setting short_open_tags at PER_DIR or stricter levels – and the php.ini-recommended disables it entirely, which means it is often disabled on end user systems.

Fortunately, we can emulate short_open_tags using stream wrappers. Adding this capability to Zend_View – and the option to disable it – would offer a flexible solution in line with our examples and messaging.

NOTE: this is currently done in the incubator.

Automatic escaping of view variables

One criticism of Zend_View is that it makes it difficult to escape variables, which does not encourage good security. One easy change would be to simply have all variables retrieved via __get() be escaped by default, and instead require developers to call a special method when they want the raw value.

This will not help in all situations – return values from view variable method calls or properties, or values from arrays would not be escaped in this fashion. An enhanced stream wrapper could solve this issue.

Helper Interface and Abstract

Currently, it's not entirely clear that you have to implement setView() in your helpers to have view awareness. Additionally, the naming conventions often get in the way, and don't follow best practices ala design patterns. The recommendation is to have a helper interface like this:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
interface Zend_View_Helper_Interface
public function setView(Zend_View_Interface $view);
public function getView();
public function direct(); // method called when helper invoked

Additionally, an abstract class implementing this would be created:

<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
abstract class Zend_View_Helper_Abstract implements Zend_View_Helper_Interface
public $view;
public function setView(Zend_View_Interface $view)
public function getView()

Helpers would then extend the abstract class and implement the direct() method as necessary.

Revisit Zend_View_Interface

Zend_View_Interface aims to make it simple to wrap alternate view implementations and retain compatibility with ZF components. However, there are some places where this falls apart: Zend_View helpers, for instance, are very useful and in some cases providing convenience features not found in other templating systems, but may not work with an alternate implementation. We should explore ways of making helpers work with such implementations.

Examine the usage of Zend_Registry for view variables

By using a registry for view variables, we would achieve a greater separation of concerns within Zend_View. Currently, much care needs to be taken when using Zend_View as a view "engine" and when it is being used as a view script "variable store". By using $registry = new Zend_Registry() (in the standard, lazy-loaded, accessor driven way), we gain this separation of concerns. __get()/_set() would need to proxy to this registry. This also would allow the ability to drop context of view script variables..

Matthew R. also talks about context in this bug:

http://framework.zend.com/issues/browse/ZF-3166

Nov 11, 2009

How can not escaping stuff in Zend_View lead to safety failures? Usually one escapes data before going into the DB. Or maybe not, but the point basically is that Zend_View can impossibly know if its data has been escaped already.

I'm not sure what the expected level of a general ZF developer is, but it seems the expectations are dropping and dropping. If developers want to show /path/../otherpath/view.phtml they should be allowed, without being overprotective and ask for some extra confirmation (ZF isn't being developed in Redmond right? <ac:emoticon ac:name="wink" /> ) by having to call a setLfi...() (whatever it was...).

Imho ZF should definitely be expecting more from its users than some morons who're just starting with PHP, and think they use OOP when they put 2 functions in one class at random. It seems odd to me why a component should do everything for me...

On a sidenote; will Zend_view in ZF 2.0 also implement the (imho) idiotic LFI protection?

Nov 11, 2009

Escaping for the database is very different than escaping for the view; they're orthogonal operations. Zend_Db actually does do automatic escaping for you already – insert() and update() operations use the adapter's native escaping operations on all passed data.

The reason for auto-escaping is to provide a poka-yoke: do the right thing by default, and if you know what you're doing, allow retrieving the raw data to do as you will. This will benefit users in a variety of ways:

security is now front and center

elimination of most calls to escape() means less typing

calling getRawValue($key) makes it explicit that you are using a raw value, and calls attention to the fact (it's easy to forget you're using a raw value otherwise)

Should we be expecting more from users? Perhaps, perhaps not. Regardless, the design as proposed is one that a number of security consultants have recommended to us multiple times during ZF's lifecycle as a good defensive practice, and a good measure towards defense in depth.

Nov 11, 2009

it's easy to forget you're using a raw value otherwise

I thought thinking about things like these is one aspect that makes the difference between a real programmer and wannabe scripters. But if that's the way to go, it's the way to go I guess.

Does this also mean we'll keep the LFI 'protection'?

Nov 11, 2009

I thought thinking about things like these is one aspect that makes the difference between a real programmer and wannabe scripters.

We have to consider all levels of developers. ZF is being used in shops that have everywhere from new to senior developers, and we need to provide tools that make creating secure applications as simple as possible. Yes, you, a seasoned developer, know to always call escape() in your views – but what about somebody with very little experience and just coming to ZF?

As for the LFI protection, it may be a moot point once we do some refactoring of Zend_View; if it's still an issue, however, yes, the code will remain. Security should be the default condition, not the other way around.

Nov 12, 2009

What about making it configurable ?

An option for Zend_View which influences the behaviour of $view->var;

by default escaping is turned on, if a developer thinks he doesn't like or want it,

he can set the option to false and $view->var returns an unmodified version of the variable.

That probably would make both sides happy and everybody can choose how he wants to use the view.

Nov 12, 2009

I should have made this more clear: the plan is to continue to implement escape(), and also to make the behavior configurable. This last is key during migrations, particularly; without it, migrating view scripts will be quite difficult.

Nov 14, 2009

The problem with auto escaping is that there is a possibility of outputting content that has been escaped twice. Most of the stuff that gets outputted on my projects has already been escaped when entering into my system (yes I am talking mainly about HTML).

Escaping for Db (for security reasons), and escaping HTML is not the same. When you try to escape HTML content which uses entities, like fore example "&" for an ampersand, you end up with "&".

But, if auto escaping feature gets implemented as a configuration option I guess that should make everybody happy.

Nov 20, 2009

Like Matthew said, ZF already does the right thing with using database driver's escaping functions.

With regards to the view, I will definitely enjoy not having to type escape in every line that prints a variable.

Dec 07, 2009

I just want to add my support for auto-escaping all data sent to the view using __get() with the option to get the raw data if/when necessary. It's far too easy to miss places that should have $this->escape() and hard to find those places.

Nov 13, 2009

To Dolf - you do realise the change will mean far less typing. I don't know about wannabe scripters, but I'll enjoy not having to call escape every other line <ac:emoticon ac:name="wink" />.

I would say the main concern that may arise is how performance is impacted. I haven't checked myself but Fabien seems really sure that automated escaping is a performance killer (at least in Symfony). I haven't found that myself using the simple wrapper I have here, so my comment is only to note that checking out whatever Symfony is doing might let us escape whatever problem they are having.

Dec 06, 2009

I think in the new version there should be support for a template language built-in.

In my company we have non-programmers writing part of the views and the php default is more confusing, IMHO.

Dec 06, 2009

Imho we definitely should not. PHP itself is a templating language already, and adding an extra syntax, would only add extra abstraction that doesn't provide any benefit (except for being 'different'). This may be interesting to read: http://nosmarty.net/ , though it's aimed at Smarty, you could replace the word 'Smarty' with 'templating engine'.

Imho there's no difference between learning your non-programmers (since when do they touch code anyway?) the syntax of Smarty/other templating language or learning them the syntax of PHP itself (which by definition performs better).

Dec 07, 2009

One of the founding tenets of ZF from the beginning has been to leverage the language as much as possible – and this was one of the reasons PHP was chosen as the "templating language" used by Zend_View.

Since prior to 1.0, we have supported custom templating engines by allowing developers to implement Zend_View_Interface to drop in their own engine – so if you want to use a different templating engine or one you've rolled yourself, you can do so.

We will not officially support additional implementations, though we will accept them for the ZendX namespace (which is community supported only); we simply don't have the resources to support multiple implementations.

Dec 14, 2009

(This may be tied to the suggestion of using Zend_Registry for view variables.)

It would be good to be able to create light-weight view objects for use by other classes.

Lets say I have a Bug class, which just focuses on the features necessary for the domain model. I then introduce a BugFormatter to prepare bugs for display. This I pass a bug instance and the view, as it may need to perform escaping and such:

//perhaps in my controller...

$bug = ...

$this->view->bug = new BugFormatter($bug, $this->view);

This is all fine BUT either I pass in access to all assigned view variables (as in this example) or I end up having to clone the view object. (This way of looking at it inverts the usual helper/partial method of passing the object to the view but the problem is the same.)

What would be good is if view object were cheap and we could use lots of them (as required) to build up the final view.

Sep 28, 2010
<ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><![CDATA[I use View Helpers already to more or less accomplish what you are talking about.
class My\View\Helper\PrintBug extends Zend\View\Helper
public function printBug(Bug $bug)
// Do common formatting of bug (using partials, etc).
Then in your controller: $this->view->bug = Bug::findBug();
Then in your view: <?php echo $this->printBug($this->bug); ?>
The printBug class would be available in ALL of your view scripts and would therefore print it consistently. Am I missing what you are saying?]]></ac:plain-text-body></ac:macro>
Dec 14, 2009

One issue I am starting to run into is that for designers there isn't really an easy way to discover which variables and helpers are available to the current view script. Instead they have to go back to the Controller Action or via some plugin somewhere to discover which variables are available to them.

Sure they can do a var_dump($this), but that usually runs outs of memory depending on what's been assigned... Plus for a designer the output is cryptic.

I'm not sure if this is an issue being looked at for the 2.0 roadmap, or one that is already solved for 1.x by other means - if so, a link would be fantastic.

I'm currently researching this area myself, and it looks like a custom implementation of a view helper to list assigned variables, and documentation to view helpers seems like the way to go - at least for my own use cases.

Dec 15, 2009

I use a View Helper here which is little more than a quick class using the Reflection API (only need an overview) and some neat list formatting. It's not pretty, but a designer can call it anywhere to get an idea of what the View contains for use. It doesn't solve every problem - View still will reference View Helpers which may conceal a lot of presentation logic, so it's important to use a sensible intuitive naming scheme and have at least some minimum of reference documentation (even a quick text file is okay) so designers have something to refer back to.

Dec 27, 2009

One problem which should be also solved is related to PartialLoop.

As far as i checked some time ago (i hope things), at each item the partial file is loaded again... I think this may lead to weak performance for PartialLoop...

Dec 31, 2009

To accommodate such a change, we'd need to implement a templating engine.

Since we are using PHP as our template language, we are using include() to both locate and evaluate the view script. This allows us to execute in the current variable scope, and relies on PHP to ensure the view script is valid, executable PHP. If we were to load into memory, we would need a template compiler and code for evaluating the view scripts – which means a complete template engine implementation.

This is unlikely to happen for 2.0, if at all.

Jan 05, 2010

Is the performance actually bad? There is a presumption after all that users will employ an opcode cache as some minimum performance measure. While this can't cache opcode per se from the conditionally included file, does it not cache that file to memory (avoiding repetitive file reads) anyway at the very least?

Jan 05, 2010

Sorry i don't have some exact stats. My bad <ac:emoticon ac:name="sad" />

For one project now 5 months i saw a slow performance with using partialLoops on one view. After switching that view using just for i noticed a great improvement of speed.

As i said i don't have any specific stats right now, just pointed out the problem...

Jan 05, 2010

Didn't Matthew do some benchmarking a while back ... ? (I certainly remember him advising, on performance reasons I think, against using partials UNLESS you specifically needed the added ability to pass in model data.)

In general, for me, partials seem a good way to go – but for the advice otherwise – as does (on a tangent) the ActionStack and the action() view helper. – It all goes towards the idea I was trying to get at previously of building a view from multiple components (each themselves to some extent reusable). – It would be good if for 2.0 these natural ways of doing it didn't need to be caveated with performance concerns...

(On the Action Stack or action() view helper in particular, I've often seen the response to build a custom view helper and use that – but, especially with little actions responding to Ajaxy interactions, this often means repeating functionality that's already around in an action controller. I don't know... <ac:emoticon ac:name="smile" />)

Jan 05, 2010

Sorry Carlton, i don't hope so much on 2.0.

I see the 1.x branch with too many opened bugs to hope 2.0 would be much better...

Of course, i didn't do myself more than reporting bugs, sorry <ac:emoticon ac:name="sad" /> ... But anyway...

Jan 05, 2010

I'd reckon that's a bit too pessimistic Christian... I least I hope so... <ac:emoticon ac:name="smile" />

Mar 03, 2010

I wanted to add a use case regarding escaping data.

When you have a search form, you need to spit back the query and preprocess and escape it in pretty much every imaginable way and probably some you never thought of.

You have to deal potentially with smart quotes for queries pasted in the box. You have diacritic characters. You have suggested terms. You have pluses converted on the browser url bar...since it's a GET, sometimes people will type stuff in the URL bar and mess up the spaces and +'s and &20's. You need to properly capture + and - and phrases in quotes. They need to be spit back correctly for pagination. For suggested terms. In Meta keywords. Meta description. Title. The search input box....so when building this, I'd suggest considering a sample form I pastebin'ed here:
http://pastebin.com/teJkBRGz

Personally, I wasn't a fan of $this->escape($var)...by default it's just a wrapper to htmlspecialchars, right? Saves 3 keys? What's the point?

I'm also not a fan of automatically escaping them unless you do it the way facebook's XHP does, in a context sensitive manner: http://www.facebook.com/note.php?note_id=294003943919. In fact if there was some way to do something similar in Zend View, that might be cool...

With $this->escape, the new ZF developer, who's unlikely to look up what escape does in the code, is just a step further away from understanding what's happening to his data. But automatically escaping vars is probably even worse, IMO. It's questionable if he's more secure, but he's certainly going to feel more secure and is less likely to learn how to escape properly in PHP...

Just my 2 cents..

Question. What's the syntax going to be for pulling the raw variable in the view and then urlencoding it? urlencode($this->getRawValue($q))?

Mar 03, 2010

Joe, you don't really raise a stance either way (for or against zend view escaping), however I'll join in and voice my opinion against it.

Currently in my applications, escaping and sanitisation is all handled in the appropriate areas. Sanitisation is handled automatically via the Doctrine ORM providing I do pass the arguments over correctly to the DQL functions, and again for escaping/stripping I have made a doctrine listener such that anything I do work with is escaped/stripped appropriately. In the cases where I know the input hasn't been escaped appropriately already then I can fall back on the $this->escape (for such things as search queries).

So that being said, sanitisation, escaping and encoding really feels as though it should be left up to the developer and the way he/she plan's to implement the system. The designer/implementor shouldn't have to worry about escaping (from my experience they don't anyway), it should be handled behind the scenes by the developer.

Mar 04, 2010

Being honest, many developers don't know how to escape properly anyway. <ac:emoticon ac:name="wink" /> The escape() method always the advantage that it centralised the htmlspecialchars() parameters instead of needing to declare them everywhere. If you let developers set the encoding everywhere explicitly you're asking for problems.

The main thing missing from the roadmap anyway is how escaping automatically will work - I haven't heard anything outside the suggestion of using streams to filter the templates and dynamically add the escape calls. The other alternative is implanting all variables into a proxy chain which automatically escapes all values being extracted which are strings (the rest are pushed into another link in the chain). This would allow for adding custom methods to the proxy class, e.g. getUrlencoded(), getRaw(), etc. and may allow for setting the context default escaper. Doesn't stop being sort of fugly - having everything encapsulated in proxy objects means the cost of escaping/proxying increases in line with the number of values being output.

Streams would rely on single use regular expressions (probably faster) but make the template syntax take on magical properties, i.e. calling getRaw() on anything would be illegal syntax technically because we're relying on a stream to translate it to legal syntax on the fly. Also, would we be able to substitute stream classes, etc, to handle our context needs?

Might as well flip coins until whoever is working on Zend_View 2.0 pushes out some more proposals.

Mar 04, 2010

The most obvious way to do it would be to use __get() to auto-escape.

Thus <?php echo $this->var; ?> would automatically escape and <?php echo $this->getRaw('var'); ?> wouldn't.

Mar 04, 2010

Can't be chained if you meant via Zend_View. What is the variable is an object with methods?

This is why it's either a stream (dynamically add the escape call) or a proxy chain (escape on string retrieval from the origin object).

Mar 04, 2010

>> If you let developers set the encoding everywhere explicitly you're asking for problems.<<

True, but so far every solution sounds like a fugly problem too...

>>Might as well flip coins until whoever is working on Zend_View 2.0 pushes out some more proposals.<<

Paddy, if you were the one working on Zend_View, how would you propose handling automagically escaping vars?

Mar 04, 2010

Probably using a proxy system rather than streams. I like the concept of using streams to alter templates on the fly, but I'm wary of the magic syntax they would require - could get confusing explaining to everyone that templates are written in a pseudo PHP syntax where certain keywords get translated to valid syntax later. If we're going down that road, why not just use the template syntax and be done with it? At least the template tags can probably be extended very easily.

I'd really like to see Ralph or Matthew dedicate a little time here.

As for proxies, they carry the unusual cost of wrapping everything except printable scalars in a proxy object. This loses you some class identity (e.g. get_class()) but can transparently escape printable strings as they are extracted. Syntax remains valid common-use PHP. It also may (or should) let you add in context related methods or "escaper" classes even. It's the more object-oriented of the two options.

The context question remains tricky though. We probably will not be able to depend on Facebook's strategy so either we use context methods, or allow its configuration beforehand when passing data into the view. It's almost a separate issue to generic escaping other than which path makes it easier to implement well.

Jul 04, 2010

Hi. Not sure if it was discussed already, probably I missed it - sorry if so.

Whether ZF has IoC DI container or not - either is fine for me, but there should be a way to inject dependencies in an application anyway.

Let's assume I don't want to use Zend_Registry.

Now it's done for controllers + zend_application that have access to the container that holds the resources (or services), so at least I can get some resources I'm dependent to and utilize them in my controller.

For view helpers currently there is just no way. I can neither access the container in a view helper nor add manually created helper to the view object.

There is no way to easily extend zend_view_abstract because all those plugin members are private, so I have currently to create my own My_View implements Zend_View_Interface, copy everything from Zend_View and Zend_View_Abstract to just be able to pass the container to it and redeclare the way helpers are instantiated.

There should be a built-in way to handle this, just like for the zend_application/controllers.

Apr 08, 2011

The recommendation all along is that library code should utilize fully qualified tags, but that view scripts can and should use short tags for brevity and clarity.

I think you are wrong on this. Stream wrapper consume resources while php's short_open_tag directive are deprecated and disabled by default in recommended php.ini since ~5.2.x.

Jan 25, 2012

It would be really nice to add "linkTo" method to the Zend_View_Helper_Url.

linkTo( string $caption, array $urlOptions = array, mixed $name = null, bool $reset = false, $encode = true ) : string

should generate something like something. You could have some additional options, like the Ruby on Rails link_to helper:
http://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#method-i-link_to

(:confirm => 'Are you sure?' is really nice feature)

It's really annoying and unclear to have:

<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[<a href="<?= $this->url('default', array('controller' => 'album', 'action' => 'edit')) . '?id=' . $album->id ?>">Edit]]></ac:plain-text-body></ac:macro>

all over the code. The query string should also be passed in some nicer manner (preferably in urlOptions array to be checked against the router).