Yes my strong opinion is that we fix the problems in getting between the two, rather than putting the content in both places. In addition to adding an new issue about links/back-to-top, let's address this as well (adding some sort of mechanism to easily link to the API docs). Making people go between this guide and the API docs is *exactly* what we want people to do, especially when the alternative is maintaining the same content in two places. We have to reduce any redundancy to a minimum when I all get is volunteer labor. ;)

This comes from experience with the CakePHP manual—too much coupling just makes things so very hard to maintain. It's hard enough to get the docs complete, let alone fixed up all the time. :)


On Jan 12, 2013, at 11:47 AM, Andrew Podner <notifications@github.com> wrote:

> In en/models/setting-up-models.wiki:
> 
> > +
> > +namespace app\models;
> > +class Posts extends \lithium\data\Model {
> > +}
> > +
> > +}}}
> > +
> > +* **SHORTCUT - USING THE COMMAND LINE:** _Lithium also allows model creation via the console:  You can enter `li3 model create Posts` into the command line (assuming you have configured the command line for use) and the code above will automatically be created in a file called `\app\models\Posts.php`_
> > +
> > +[back to top](#top)
> > +
> > +<a id="options"></a>
> > +---
> > +
> > +## Setting Model Options
> > +#### ModelName::meta([$key], [$value])
> I understand your logic there; the only pitfall I can potentially see is that it kind of creates 2 manuals for the user to have to move back and forth between which is not necessarily a problem if:
> 
> the person reading the user guide knows they need to go to the 2nd manual
> the 2nd manual is as clear & concise
> Thinking about it from a new user perspective, there may be a consideration of the "one stop shop". I go to the user guide, I get the answer, end of transaction. I agree that it does make the user guide a higher maintenance proposition, but at the same time, it does accomplish 2 other things:
> 
> It distills all relevant instruction and documentation into a single location
> The API docs are going to cover a lot of protected and private methods that may clutter the user's ability to quickly navigate to the specific information, particularly since the API methods & properties are not listed in logical order (e.g. alphabetical).
> Just a devil's advocate thought process to consider. I can do it in any way that is acceptable.
> 
> —
> Reply to this email directly or view it on GitHub.
> 
>