search

CouchCMS / Documentation

Documentation for CouchCMS
http://docs.couchcms.com/
6 stars 3 forks source link

type = 'textarea' #1

Closed fallingsprings closed 9 years ago

fallingsprings commented 9 years ago

Page: http://docs.couchcms.com/tags-reference/editable/textarea.html

The code sample for the Width and Height parameters is missing type='textarea'. The indentation is also non-standard:

<cms:editable name='prop_desc' label='Description'
 desc='Enter description of property here'
 width='400'
 height='200'
/>

should be:

<cms:editable name='prop_desc' label='Description'
    desc='Enter description of property here'
    width='400'
    height='200'
    type='textarea'
/>
cheesypoof commented 9 years ago

Yes, I have noticed as well that the indentation in code samples is not consistent throughout the documentation. I am reluctant to go through this myself, or encourage anyone else to do so...

The default editable region type is textarea (even though the docs state otherwise). Therefore, in this case, it need not be specified. I concede that its absence is confusing though...

I'll fix these issues after I correct some problems that seem to have cropped up as a result of an update to the markdown parser.

Thanks for the report @fallingsprings.

fallingsprings commented 9 years ago

I am reluctant to go through this myself, or encourage anyone else to do so...

I don't mind pecking away at these inconsistencies, little-by-little, if you don't mind being the spigot the changes run through. I do think that type='textarea'should be included in the snippet even if it is the default, just for clarity and consistency in declaring editable regions.

While you straighten out the problems you've run into, I'll work on learning the workflow and markdown syntax. Then I'll be in a better position to contribute.

cheesypoof commented 9 years ago

I actually would like to keep the focus mainly on non-stylistic matters. So if you wouldn't mind @fallingsprings, could we leave the code indentation matter alone for now?

The problems I mentioned have been resolved.

I will create a new issue that lists known outstanding tasks (that anyone can take on).

fallingsprings commented 9 years ago

Cool. That's what I want to know. The best way to contribute without being a fly on your nose.

So when it comes to random details like this that I find while using the documentation, I guess the bug reporter would be the best method. How about unsolicited pull requests? I went through the steps of cloning the repository and building from source on issue #2 (URL validator). Would you like me to send a new pull request for that? Or just wait and pick up tasks from the list?

I'm not too familiar with git, especially the collaborative tools, or with Markdown. I'm willing to learn and pitch in, but I don't want to make that your problem. Let me know what you would be best for you.

cheesypoof commented 9 years ago

Unsolicited pull requests are not a problem. If it involves a significant time commitment though, you probably should create an issue first - we don't want to waste any contributor's time.

You can always rebase and squash commits in git. So generally, closing a pull request is unnecessary for those reasons (like in this case for #2). I fixed up and merged the changes.

Thanks.