Leaderboard
Popular Content
Showing content with the highest reputation on 05/03/2012 in all areas
-
Diogo - Your last post worked perfectly!!! Thank You so much - very new to ProcessWire (looking for WordPress replacement) and so far loving me sum ProcessWire.2 points
-
You guys got me thinking about this form builder and now I can't get my mind off it. I've taken a look at Netcarver's and Zend's form classes, and both look awesome. I'm particularly impressed by Netcarver's system and hope to be putting it to use sometime soon. Focusing on this a lot the last few days also made me realize that a PW formbuilder and the existing Inputfields have a lot of common ground. Enough so that it probably doesn't make sense for a PW formbuilder to venture outside of that. But it does make sense to upgrade PW's Inputfield system to make it more flexible consistent with the needs of a formbuilder. It's easier to maintain and support if there is one system rather than two. It wouldn't replace a system like Netcarver's or Zend's, but would provide a good middle ground for the less complex form needs. As a first step, I figured I'd see how well Inputfields would adapt for the sort of portability a formbuilder would need. The goal was to be able to take an array or JSON string, and have it render as a form using PW Inputfields, as they are now. This is something I'd not tried before, but the first step we'd need in order to easily store a form schema for a form builder. A small 20-line recursive function takes that array and dynamically creates a form composed entirely of PW Inputfields. All that's left to do is call $form->render(); I built a small test form and had success with it. Yesterday a friend needed help on a larger form, so decided to put the strategy to work there too. Here is the result. Not a pretty form by any stretch, but I was happy with how easily it all went together, and now getting me enthusiastic about going further with full blown form builder. As an example, here's the PHP array schema for my test form: $formArray = array( 'personal_info' => array( 'type' => 'Fieldset', 'label' => 'Personal Information', 'children' => array( 'first_name' => array( 'type' => 'Text', 'label' => "First Name", 'columnWidth' => 50, 'required' => true, ), 'last_name' => array( 'type' => 'Text', 'label' => "Last Name", 'columnWidth' => 50, 'required' => true ), 'email' => array( 'type' => 'Email', 'label' => "Your Email", 'columnWidth' => 50, 'required' => true ), 'phone' => array( 'type' => 'Text', 'label' => "Your Phone", 'columnWidth' => 50, 'required' => true ) ) ), 'customer_feedback' => array( 'type' => 'Fieldset', 'label' => 'Share Your Feedback', 'children' => array( 'store_location' => array( 'type' => 'Select', 'label' => 'What store location did you visit?', 'options' => array( 'ATL' => 'Atlanta, GA', 'CHI' => 'Chicago, IL', 'NYC' => 'New York, NY', 'SFO' => 'San Francisco, CA' ) ), 'would_visit_again' => array( 'type' => 'Radios', 'label' => 'Would you visit that location again?', 'options' => array( 'Y' => 'Yes I would', 'N' => 'No I would not' ) ), 'comments' => array( 'type' => 'Textarea', 'label' => 'Comments or Questions?', 'description' => "We'll respond right away!", 'rows' => 5 ) ) ), 'submit' => array( 'type' => 'Submit', 'value' => 'Submit Your Feedback!' ) ); That schema can be converted to/from JSON just by calling json_encode/json_decode on it, and gives us exactly the portability I'd want out of it. Given that this can be translated to a full form of Inputfields with a tiny function (arrayToForm), I figured that's a great first step towards an interactive formbuilder. Here's what the template code looks like: $form = arrayToForm($formArray); if($form->isSubmitted()) { $body = "<html><body>" . $form->renderValues() . "</body></html>"; $headers = "Content-type: text/html; charset=utf-8\nFrom: " . $form->get('email')->value; mail('me@domain.com', 'Form Submission', $body, $headers); echo "<h2>Thanks, your form was submitted!</h2>"; } else if(count($form->getErrors()) { echo "<h2>Fix the fields in red and try again.</h2>"; echo $form->render(); } else { echo $form->render(); } That's how I'm doing it now, but stuff like the above would obviously be integrated into a FormProcessor class so that you only need to call 1 function to display/process a form, and you could store and browse the results in a DB rather than just emailing it. Inputfields need to be upgraded so that all the structural markup is customizable. I'd probably want the default render output to be structured around fieldsets rather than lists, and be something that one wouldn't necessarily need any prerequisite CSS/JS except for progressive enhancement. Other upgrades would be more validation options for the basic Inputfields. The nice thing is that any upgrades would benefit all of PW, not just the formbuilder. The next test/proof-of-concept will be to make the creation of that $formArray interactive from the admin (with a Process module).2 points
-
Would anyone be interested in a ProcessWire-themed meetup/social gathering in the UK?1 point
-
Hello all, I've just pushed textile 2.4 up to github should anyone wish to try out some of the new features. If you do try it out, please keep me informed of your successes or failures with it. Download instructions are at the end of this post. What's New? Quite a lot... Support for HTML comments. Support for extended characters in URLs. Support for Redcloth-style definition lists. More robust handling of notelists and note definitions. Support for linebreaks in table cells. Support for apostrophes following abbr/acronyms. Support for ordered list continuation/start control. More robust detection of lists so that even those which are not separated from the previous text are found. Customisable format for footnote refs and marks and for notelist refs. And here are some examples of the above to help you get started 1: Support for HTML comments. Previously having HTML comments embedded in your textile source code could lead to broken output. You should now be able to get well formatted output even if you feed it things such as... Here is some text with a <!-- Commented out[1] --> block. <!-- Here is a single <span>line</span> comment block --> <!-- Here is a whole multiline <span>HTML</span> Comment --> bc. <!-- Here is a comment block in a code block. --> 2: Support for extended characters in URLs. You can now do this... "Übermensch":https://de.wikipedia.org/wiki/Übermensch "äöüÄÖÜßçéáóúèàòùÉÁÓÚÈÀÒÙêÊôÔâÂûÛåÅœŒæÆøØëËïÏ with trailing slash":https://en.wikipedia.com/ä/öüÄÖÜßç/éáóúè/àòùÉÁÓÚ/ÈÀÒÙêÊôÔâÂû/ÛåÅœŒæÆøØëËïÏ/ ...and get correctly formatted links. However, if your link has non-word characters at the end then you have to use textile's link alias feature to get them correctly recognised and encoded. So for things like... http://msdn.microsoft.net/en-us/library/cby9kycs(v=vs.80).aspx (brackets + multiple periods) http://ja.wikipedia.org/wiki/福島駅_(大阪府)/ (brackets) ...you would need to do this... Contact "Microsoft":myalias1 or check out "福島駅":myalias2. [myalias1]http://msdn.microsoft.net/en-us/library/cby9kycs(v=vs.80).aspx [myalias2]http://ja.wikipedia.org/wiki/福島駅_(大阪府)/ 3: Support for Redcloth-style definition lists. Although PHP-textile has supported definition lists for a while, this version adds support for the redcloth definition list syntax. So you can now define lists so... - coffee := Hot _and_ black - tea := Also hot, but a little less black - milk := Nourishing beverage for baby cows. Cold drink that goes great with cookies. =: 4: More robust handling of notelists and note definitions. Textile is pretty picky about its notedef and notelist syntax. Prevoiusly both had to be terminated with a period. As users seem to miss these out fairly regularly I've relaxed this and now your notedefs and notelists don't need to end with a . 5: Support for linebreaks in table cells. You should now have newlines converted into <br /> properly in tables now. 6: Support for apostrophes following abbr/acronyms. Previously apostrophes following abbr/acronyms were not being encoded correctly, showing up as an open-single-quote mark. These should now work just fine... NATO(North Atlantic Treaty Organisation)'s pretty big. The NHS(National Health Service)' charter states... 7: Support for ordered list continuation/start control. When starting an ordered list you can now specify the start attribute to be applied like so... #8 Item 8 # Item 9 And if you want to continue a list's numbering from where you previous ordered list finished you can let textile know using the continuation character... #_ Item 10 # Item 11 8: More robust detection of lists so that even those which are not separated from the previous text are found. I've relaxed the constraint that lists have to be separated from what comes before them by two newlines. So the following example will still correctly generate a list... A list of colours. * Red * Green * Blue 9: Customisable format for footnote refs and marks and for notelist refs. Some languages need a slightly different way of showing footnote references in the main text (or indeed, marking them in the foot itself) so you can now define your own format before you include classTextile.php in your project. Please look at the commit messages here and here for more details. Getting the file... If you do want to try it out and have an existing installation of PW or Textpattern which use textile then you can follow these steps to get the release candidate installed... Backup your existing classTextile.php file. Click here to access the new, raw, classTextile.php Save this over your existing file.1 point
-
I have run a wiki before (different software, so not much help), and they do attract spam like flies to something or other, so I'd recommend battening down the hatches sooner rather than later.1 point
-
Or, iterate over all images: foreach($page->my_repeater-area as $building) { echo "<p>{$building->building_description}</p>"; echo "<p>{$building->building_text}</p>"; foreach($building->building_image as $img) { echo "<img src='{$img->url}' alt='{$img->description}' />"; } }1 point
-
There are polyfills for the HTML5 placeholder attribute (i.e. pieces of usually javascript to replicate a certain feature in browsers who do not provide it natively). The Modernizr wiki on GitHub has a pretty comprehensive list of them. Personally, I think placeholder doesn't need to be polyfilled, it's fine to not have it in older browsers. If that's not feasible, the polyfill by Mathias Bynens works pretty good.1 point
-
This looks great Ryan. If you take this a step further with the input formatting done in YAML or Neon then you'll have a super-terse way of defining your form structure.1 point
-
I totally agree with Ryan on this. I don't think Aloha is appropriate for 100% of problems, but it doesn't need to be to be useful. As Ryan says, it's a cool little utility that provides a useful function and I personally would love to see support for it.1 point
-
I also meant to add that I think this thing would best be developed as a module on it's own. I know that this came up in talking about AdminBar, but AdminBar's utility is clearly far greater than that of any inline editor. Or to word it differently, I would install AdminBar on all sites, but I would only install Aloha as another option in some cases. The two could of course also run together, but it seems like Aloha should probably exist as an independent 3rd party module rather than integrated into anything else (if that was even a consideration). If anyone else decides to develop an Aloha editor module, let me know. Otherwise, I will probably put one together at some point in the near future because it seems like it will be pretty easy to do (building from the code posted earlier). I mentioned above that AdminBar is something that I would install on all sites (and I'm guessing more than half of others would too). I think it might make sense for AdminBar to be a core module (maybe with 2.1 or 2.2 release?). That way it would be ready to install (1-click) for anyone that installs ProcessWire. Antti, would you have any interest in this, or would you prefer to keep it separate?1 point
-
Nice AdminBar updates! I've installed it on the site I'm developing now and I know the client will love this. I'm not suggesting that inline editing would ever be a replacement for existing editing tools. Nor am I suggesting it should be part of the core (just a 3rd party module option). And I probably wouldn't use it myself. It goes against CM accessibility best practices– content shouldn't have a specific presentation context dependency. But I do think there are some situations where it would be a useful option to provide... like when the needs are really simple and the client is your Grandma (and I can think of other cases, few and far between). But the main reason I like it is... Putting on my salesperson hat– If I going in to pitch a proposal for a site and I can show the client that they can update their address, phone, headline, directions, etc., right in the page where it appears, then I've just sold the decision makers. Many times, these people don't understand content management best practices and may not even know exactly what a CMS is (and rarely are they the ones that will actually use it). They understand the concept of print and printing-presses, and they don't like thinking beyond those boundaries. Dynamic content is an abstract concept that's understood only as a buzzword. These are the folks I have to convince. Despite the drawbacks of inline editing, these people will "get it" immediately, and I will be their problem solver. When the next guy comes in pitching the benefits of taxonomies and nodes, then they won't even be listening. So whether or not the inline editing capability is useful or good is debatable. But I think we can all agree it's at least compelling eye candy that can help to market a product and connect with a broader audience.1 point
