Answers.Body: <p>For most uses of <code>CRM_Core_Form-&gt;add()</code>, all the arguments you need are in the docblock:</p>
  
  <pre><code>  /**
     * Simple easy to use wrapper around addElement.
     *
     * Deal with simple validation rules.
     *
     * @param string $type
     * @param string $name
     * @param string $label
     * @param string|array $attributes (options for select elements)
     * @param bool $required
     * @param array $extra
     *   (attributes for select elements).
     *   For datepicker elements this is consistent with the data
     *   from CRM_Utils_Date::getDatePickerExtra
     *
     * @return HTML_QuickForm_Element
     *   Could be an error object
     */
  </code></pre>
  
  <p>Datepicker is a special case, and is <a href="https://docs.civicrm.org/dev/en/latest/framework/ui/#date-picker" rel="nofollow noreferrer">documented separately</a>.  I found this by searching <code>CRM_Core_Form</code> for "datepicker" and found a reference to this as a comment.</p>
  
  <p>As some unasked for commentary - if you can find any way to NOT use Quickform, I highly recommend it.  It's pretty much every Civi dev's least favorite part of Civi, and there's an active effort to replace it.  Consider using AJAX/API wherever possible to make your life easier!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T22:10:32.377Z
Answers.Text: Wow, interesting answer, especially that last part. Good to hear, frankly, as I'm not loving it either. So, what would you recommend inside an extension for creating pop-up forms both for viewing data and submitting changes? What's the new recommendation? Just building out my own custom form page with AJAX calls or is there a certain framework/toolset we should all be using? The civix tool creates the Quickform files, that's why I started with that, thought that was the "proper" Civi thing to do. But happy to use whatever should be the new norm.
Answers.UserDisplayName: Paul B
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T22:41:21.107Z
Answers.Text: @PaulB   The docs [(very) quietly discourage using forms](https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-form).  If you're savvy with AngularJS, quite a bit of Civi is written in that and there are helpers (including in civix).  If the extension is for private use, you can use whatever JS framework of the week suits your fancy. If you want to generate your pages using PHP, check out the [in-place field editing](https://docs.civicrm.org/dev/en/latest/framework/ui/#in-place-field-editing) docs, also [this similar SE question](https://civicrm.stackexchange.com/q/14767/12).
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-22T10:11:15.757Z
Answers.Text: @PaulB I still use the Quickform files as the supported Angular version is deprecated as well :-) So there are more answers and opinions, as in any community :-) I understand the opinion of JonG and at the same time I try to live by "nothing is changed until it is changed"  and in my experience the Quickform stuff is pretty reliable and I know my way around it. I would have to invest time to learn AngularJS, some other developer in my team has tried and mentions creating the stuff with AngularJS does not really save him any time so why should I?
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-22T14:07:28.147Z
Answers.Text: All, this is great discussion glad to see an active community. Totally understand, so much is changing all the time, and lots of opinions out there. I created an AngularJS app a while ago which I was comfortable with at the time, but as you said, that's now moved on to another release (totally different). It would be interesting to see where the core dev team heads with later releases of Civi, I just want to make sure I follow their lead/best practices (and it sounds like that's not yet agreed upon, which is healthy, I think, just interesting as I learn more). Appreciate all the feedback here.
Answers.UserDisplayName: Paul B
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T18:23:16.977Z
Answers.LastActivityDate: 2019-05-21T18:23:16.977Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.Body: <p>I usually find more detailed examples by looking in the CiviCRM code, which is exactly where I found the answer to the " i do not want time" question a while ago :-)
  As I found it I can share it with you: </p>
  
  <pre><code>$this-&gt;add('datepicker', 'activity_compare_date', ts('Comparison Date'), array('placeholder' =&gt; ts('Compare with')),FALSE, array('time' =&gt; FALSE));
  </code></pre>
  
  <p>And yes,it would be ideal if all these examples would be in the developer guide. So I would like to invite you to the next CiviCRM sprint to make this happen :-)</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T13:45:01.060Z
Answers.Text: Thanks much! I had been hunting through code but didn't find that example. Appreciate it.  Now if I had any clue how Quickform works, I'd be happy to help document :-). It's my first time building a legit form, I've been doing things a hacky way all this time. And now I know why, this is some confusing stuff at first. What you pasted there is a good example, there is another array after attributes, I have no clue what options can go in there, nor what that boolean is doing in the middle there :). Much to learn. Would be great to have that cheat sheet linked in the docs updated.
Answers.UserDisplayName: Paul B
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-22T10:12:00.343Z
Answers.Text: The boolean in the middle is for required
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-05-21T12:54:17.890Z
Answers.LastActivityDate: 2019-05-21T12:54:17.890Z
Answers.UserDisplayName: ErikH - CiviCooP
Body: <p>I'm building my first extension with a basic Quickform. I'm trying to figure out the options I have for different field types, but I'm not seeing where the documentation is on definitions of types, especially the extended types.  For example, the <a href="https://docs.civicrm.org/dev/en/latest/framework/quickform/" rel="nofollow noreferrer">Developer Docs</a> talk about deprecated types for dates, and they mention using datepicker, but where would I find all the options I have available to me for the datepicker type? In this case, I'd like to have a datepicker without the time part, or set the minimum date. But same goes for other types as well, I'm not seeing the documentation or examples.  Where can I get more details on each extended type and/or examples of use?</p>
  
Tags: <quickform>
Title: Quickform Types Definitions or Examples
ThreadText: # Quickform Types Definitions or Examples
  
  (Asked by: username_0 on 2019-05-20)
  
  I'm building my first extension with a basic Quickform. I'm trying to figure out the options I have for different field types, but I'm not seeing where the documentation is on definitions of types, especially the extended types. For example, the [Developer Docs](https://docs.civicrm.org/dev/en/latest/framework/quickform/) talk about deprecated types for dates, and they mention using datepicker, but where would I find all the options I have available to me for the datepicker type? In this case, I'd like to have a datepicker without the time part, or set the minimum date. But same goes for other types as well, I'm not seeing the documentation or examples. Where can I get more details on each extended type and/or examples of use?
  
  **Tags:** quickform
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-05-21. Score: 1 | Accepted answer
  
  For most uses of CRM_Core_Form->add(), all the arguments you need are in the docblock:
    /**
     * Simple easy to use wrapper around addElement.
     *
     * Deal with simple validation rules.
     *
     * @param string $type
     * @param string $name
     * @param string $label
     * @param string|array $attributes (options for select elements)
     * @param bool $required
     * @param array $extra
     *   (attributes for select elements).
     *   For datepicker elements this is consistent with the data
     *   from CRM_Utils_Date::getDatePickerExtra
     *
     * @return HTML_QuickForm_Element
     *   Could be an error object
     */
  
  Datepicker is a special case, and is documented separately.  I found this by searching CRM_Core_Form for "datepicker" and found a reference to this as a comment.
  As some unasked for commentary - if you can find any way to NOT use Quickform, I highly recommend it.  It's pretty much every Civi dev's least favorite part of Civi, and there's an active effort to replace it.  Consider using AJAX/API wherever possible to make your life easier!
  
  > **Comments:**
  > **username_0**: Wow, interesting answer, especially that last part. Good to hear, frankly, as I'm not loving it either. So, what would you recommend inside an extension for creating pop-up forms both for viewing data and submitting changes? What's the new recommendation? Just building out my own custom form page with AJAX calls or is there a certain framework/toolset we should all be using? The civix tool creates the Quickform files, that's why I started with that, thought that was the "proper" Civi thing to do. But happy to use whatever should be the new norm.  
  > **username_1**: @PaulB   The docs [(very) quietly discourage using forms](https://docs.civicrm.org/dev/en/latest/extensions/civix/#generate-form).  If you're savvy with AngularJS, quite a bit of Civi is written in that and there are helpers (including in civix).  If the extension is for private use, you can use whatever JS framework of the week suits your fancy. If you want to generate your pages using PHP, check out the [in-place field editing](https://docs.civicrm.org/dev/en/latest/framework/ui/#in-place-field-editing) docs, also [this similar SE question](https://civicrm.stackexchange.com/q/14767/12).  
  > **username_2**: @PaulB I still use the Quickform files as the supported Angular version is deprecated as well :-) So there are more answers and opinions, as in any community :-) I understand the opinion of JonG and at the same time I try to live by "nothing is changed until it is changed"  and in my experience the Quickform stuff is pretty reliable and I know my way around it. I would have to invest time to learn AngularJS, some other developer in my team has tried and mentions creating the stuff with AngularJS does not really save him any time so why should I?  
  > **username_0**: All, this is great discussion glad to see an active community. Totally understand, so much is changing all the time, and lots of opinions out there. I created an AngularJS app a while ago which I was comfortable with at the time, but as you said, that's now moved on to another release (totally different). It would be interesting to see where the core dev team heads with later releases of Civi, I just want to make sure I follow their lead/best practices (and it sounds like that's not yet agreed upon, which is healthy, I think, just interesting as I learn more). Appreciate all the feedback here.  
  
  ---
  
  ### Answer by username_2 on 2019-05-21. Score: 3
  
  I usually find more detailed examples by looking in the CiviCRM code, which is exactly where I found the answer to the " i do not want time" question a while ago :-)
  As I found it I can share it with you: 
  $this->add('datepicker', 'activity_compare_date', ts('Comparison Date'), array('placeholder' => ts('Compare with')),FALSE, array('time' => FALSE));
  
  And yes,it would be ideal if all these examples would be in the developer guide. So I would like to invite you to the next CiviCRM sprint to make this happen :-)
  
  > **Comments:**
  > **username_0**: Thanks much! I had been hunting through code but didn't find that example. Appreciate it.  Now if I had any clue how Quickform works, I'd be happy to help document :-). It's my first time building a legit form, I've been doing things a hacky way all this time. And now I know why, this is some confusing stuff at first. What you pasted there is a good example, there is another array after attributes, I have no clue what options can go in there, nor what that boolean is doing in the middle there :). Much to learn. Would be great to have that cheat sheet linked in the docs updated.  
  > **username_2**: The boolean in the middle is for required  
  
  ---
  
  