function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Poll: Help Enhance Visualforce Documentation!

The documentation team is currently looking for ways to combine reference material across several technologies--like the API, Apex, and Visualforce--into a single guide. The goal is to ease developers from the burden of switching between two or even three guides when trying to work on a project.


If you had to choose, what information about the platform would you like to see added to the Visualforce guide? Some examples include:


  • Reference material from the API on standard objects and their fields
  • A list of SOSL and SOQL calls that can be used in custom controllers
Message Edited by jwetzler on 01-12-2010 11:41 AM


     Component refrencepage was not propely updated based updated please look into it.

I would like to see various tasks done in visual force, along with more detailed explanation of how to construct controllers and extensions to make these work.
Rajesh ShahRajesh Shah
In the Apex Code Developer's Guide, we have the Reference section. If that could also be included in the Visualforce Guide.

If this is off the subject I appoligize but I would like all of the old S-Control codes to be updated to Visualforce. I still see alot of S-Controls out there that I can not use.



I'd like to see some documentation on the lower level generation of a page.  For example, when property getters are called - I know from coding/testing that they can be called more than once, but not why this is.  

The docs are very incomplete IMO. They should include every parameter, attribute, value, etc that the system recognizes as opposed to giving samples of each. For instance, take a look at the the "param" section of the VF guide. Where does it explain the meaning of "firstParam" when used in the "name" attribute, or other possibilities with the "value" attribute other than the one provided in the example (the My {0} example). There may not be any other possibilities, in which case this should be clearly stated.



Message Edited by asadim2 on 01-18-2010 01:03 AM

Thank you for your suggestions, I can certainly pass them along to the Visualforce doc writer.


I'd like to reiterate the original point of the thread though, which is: Out of the existing documentation, what would you like to see combined that would stop you from having to have three or four different PDFs or tabs open while you're developing?



     It is another request we need good example code in VF.


I actually don't mind having three tabs open. In reality though it is usually only two, Apex and Visualforce reference guides. Rarely do I use the API doc as I'm not really builder 3rd party apps. And if you are viewing the PDFs you can have these tabbed with in the viewer. (Foxit PDF view, ditch Adobe and get this)


I would much rather have specific documentation for each. Combining them could be a slippery slope to complicatedness (yes, its actually a word). Where they are combined, and this works, is the developer guide and cookbooks. 


I don't feel there is a need for anything more than updated and improving the current documentation set.

Message Edited by TehNrd on 01-18-2010 03:54 PM