Frequently Asked Questions

Can I use Agavi in a proprietary, commercial application?

Of course. The GNU LGPL license explicitly allows this. An application built with Agavi is, in terms of the license, not a derivative work, but a work that uses the library:

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

Should you modify any of Agavi's source code, you need to share these modifications with the world. In reality, this is not an issue with Agavi, since any functionality or behavior can be overridden or extended by subclassing or replacing Agavi's implementations, which is perfectly fine with the LGPL:

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

Check out http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License for more explanations.

Why doesn't Agavi have user forums?

First of all, let us make perfectly clear that there is no need to argue about this. Agavi does not have a forum, and it never will have one. But you probably still wonder why that is, so let's get to explaining the reasons why we rely on mailing lists instead.

Forums have various problems. The first one is that they require active involvement from the users in order to be read. Unlike a mailing list, where the messages flow to your inbox by themselves, you have to remember to visit forums to keep track of postings. Yes, forum softwares these days have RSS feeds, but you cannot post replies that way, you still have to go to the forum website and write it up. And you have to be online to do that. And with or without RSS, you need to go through all the topics and see if there are replies you missed, even though the built in features in most forum engines works reasonably well in that regard by taking you to the first unread item. Still, forums are very time intensive, and most developers don't have too much time on their hands.

As you can imagine, the amount of time people spend on forums varies greatly depending on how busy they are. And if they have an internet connection. But that's not the real factor in why forums are a bad idea. The real factor is that over time, people acquire knowledge, and then they don't use the forums anymore because there aren't many topics left that are of any interest to them. But the users with knowledge are essential for quality support, and if they don't visit the forums, the forums are mostly frequented by beginners who don't have much of a clue. If you look around on other message boards, you have 90% beginners which give other beginners bad advice, 5% on the edge of being skilled enough not to need the forums anymore, and 5% developers themselves who have too much time or volunteers with a severe helper syndrome. But those five percent cannot provide solid support. Just look at typical open source software message boards, where the majority of forum topics has no replies. In contrast, no mailing list topic on the Agavi users list ever went unanswered. And mailing lists have excellent support quality because the gurus and wizards that have the really good answers need to spend way less time consuming the messages.

Oh and then, of course, there are the two reasons that really count. First, the community decided they want mailing lists, not forums. And secondly, forums get too much viagra and poker spam anyway :)

And yes, we know what we're talking about, because we once had message boards, and they were horrible. And no, all the other arguments you had in mind just don't apply. There are two others which are especially significant:

Mailing lists are difficult to use for beginners

If someone who calls himself a software developer is too stupid to sign up to a mailing list, he should consider a new job that fits his skill set.

Forums are so much easier to search

Mailing lists don't get off-topic as easily, so they actually contain much less noise, and thanks to archives, mailing list are just as easy and comfortable to search through and link to as forums.

Layers and Layouts?

A minimalistic introduction to layers and layouts

A view in Agavi can either return content (a string or a stream resource) or instruct the execution filter to render a bunch of layers. You can either build these layers by hand, or you conveniently load them using a layout. Layouts are defined in output_types.xml and they just define layers, their names, their renderers, their slots etc. Most often this is all you need.

If you want a "normal" layout and a simple layout without a decorator, you'd simply do:

<layouts>
	<layout name="default">
		<layer name="content" />
		<layer name="decorator">...</layer>
	</layout>
	<layout name="simple">
		<layer name="content" />
	</layout>
</layouts>

Then (in the view) loadLayout() loads the default loadLayout('default') loads the default and loadLayout('simple') loads the simple layout. The Decorator layer of course needs the static definitions for templates through parameters, but that's all in the sample sources The system actions that ship with the Agavi code templates build layers and renderer instructions by hand. The reason for that is that 404 etc would simply break if you use a layout for those and the user changes the default renderer to, say, AgaviSmartyRenderer?.