How to render a simpelt inputfield markup??

[Biorn]

Hi guys..

I was wondering..

How do I render or output simpel <input> markup??

The list output that InputfieldForm makes is tomutch..

Im loading a template (without file) and I want to output the same fields as a form in the frontend..

Thanks for all your work...

[teppo]

If I understood correctly what you're after, you should check out Form Template Processor (http://modules.proce...late-processor/.) That module does pretty much exactly what you've described above.

Edit:

After re-reading your post, I'm afraid that Form Template Processor might also be somewhat overkill for your needs. I'd still recommend to check it out, but in case that you simply want markup for inputs, you could probably foreach through $template->fields() and for each field you want displayed call $field->render().

That approach would require quite a bit more work than simply using Form Template Processor or something similar, but if that's definitely what you want then it's one possibility.

Edited September 29, 2012 by teppo

[Biorn]

!! hirvi hyppii kukku paivan !!

Well, I have looked into the formProcessor, and Im using it on some other sites..

And its ok, but its rendering a whole lot of html.. And thats a bummer..

And I allso like to push some extra stuff into it..

The formBuilder is allso rendering to mutch, and Its not 100% yet.. But I have high hopes..

Im starting to get a little tired, have looked into it for 30h now.. Maybe, I need some sleep..

[diogo]

Does this help?

[Biorn]

Sorry, its the inputFieldWrapper again..

alot of markup..

Thanks for it anyway..

[apeisa]

I guess your only option is to loop through $template->fields() and generate your own markup for each field.

[Biorn]

Thats ok, but how can I be shure I get all the right attributes and other stuff for the fields??

[diogo]

Have a look at the output of this to know what are the attributes that would be important to target on each field.

foreach($page->fields as $f) {
 echo "<pre>";
 print_r($f);
 echo "</pre>";
}

[Biorn]

Ok..

And the inputtypeXXXXjust need to beed str'ed and switch..

I think I got it...

hmmm... module anyone..

[ryan]

The formBuilder is allso rendering to mutch,

There is actually a reason for every bit of markup that appears in ProcessWire's generated forms, whether from the admin, Form Builder or elsewhere (they are all using the same Inputfields system). Once you start removing things from it, you likewise remove some feature, capability or customizability from it. In some cases, you might even remove the possibility of supporting certain types of inputs.

That may be difficult to appreciate if you only look at it from the markup side, because it might be different from your own markup when making your own forms. Most notably, we have more wrapper elements and class names present than you would usually need in a standard HTML form. But these are not standard HTML forms, and you should avoid looking at it as such. ProcessWire forms have to cover more terrain than a typical web form. The Form Builder has to provide the capability of accommodating any type of layout, theme, or input (known and unknown, whether regular HTML or JS-based) with a common markup. Once you really start pushing Form Builder or ProcessWire forms, I think you can start to appreciate what the markup brings.

Creating a form is the primarily purpose of what a form builder is for. When you are creating your own form markup, then you are the form builder. So my advice is that when you want to use Form Builder, let it do what it is designed to do and it will perform beautifully for you. On the other hand, when outputting a specific markup is more important than the result, then don't use any kind of form builder. A form builder is by nature a markup generating tool aimed at giving you really powerful forms quickly. And ProcessWire Form Builder is an expert at what it does. But you have to trust it and let it do its job.

and Its not 100% yet.. But I have high hopes..

I've been both developing and using Form Builder for several months now, and strongly feel it is 100%. That's why I've moved it from beta to stable this last week. It is the most comprehensive and complete module ever built for ProcessWire (at least of those that I've built), including the core modules. Like mentioned above, you do have to use it in the way it is designed to be used and in the way it recommends. If you come across any issues or bugs that lead you to think some part is not 100%, then just let me know what it is -- I fix things very quickly. But I am not aware of any issues at present. At least, it is 100% stable with all the forms I am using it on at present.

[Biorn]

I know I know..

But I thinking on a front-end large form thingy, base on a css grid..

and some fields are predefined..

here is the header im working with atm..

<form . . .>
<div class="row">
<div class="span6">
<label . . . >bla bla</label>
<input . . . >
<label . . . >bla bla</label>
<input . . . >
<label . . . >bla bla</label>
<input . . . >
</div>
<div class="span6">
<label . . . >bla bla</label>
<input . . . >
<label . . . >bla bla</label>
<input . . . >
</div>
</div>
</form>

here im using twitters bootstrap, and its responsive..

[diogo]

You can always hide all the other things with css

[Biorn]

Yup, and do some aften rendeing manipulation with jQuery..

Puts it still have do render and load the markup, and I want it snappy.. and usable on different platforms... phones, tablets and laptops..

[teppo]

So, basically you want to render a form with exactly the markup that Twitter Bootstrap requires, right? If that's the case, then I would imagine your only chance (right now) being looping through fields and generating markup on the fly yourself. There's no shortcut for this one, I'm afraid.

Depending on your form and how static it is, this might be an easy task or a very difficult one. If you're only having to deal with text inputs and textareas, it shouldn't require too much work - but supporting all possible fields (especially images, files etc.) would be a real pain. Try to keep things as simple as possible

[ryan]

I think you are better off using the Form Builder inputs as-is rather than the Twitter Bootstrap ones. Twitter Bootstrap is a partial solution, whereas Form Builder is a full solution. Form Builder output is also responsive -- just put it in a container the size that you need it and it will adapt to the container whether mobile scale or desktop scale. What it won't do is switch from multi-column to single column when small width, so your use of column width should target mobile rather than desktop, when used in responsive output.

In order to avoid conflicts with Twitter bootstrap styles, stick to embed option A or B, which use iframes. If that doesn't work for your case, you can use embed option C, but you'll likely have to do some CSS tweaks to make it look good.

If you are going to be limiting yourself to just the basic input types, you can also change the wrapper markup from the module settings screen. From here you could introduce more bootstrap-specific wrapper elements, for instance. But once you start doing that, you'll lose some of the things that Form Builder is giving you like fieldsets, collapsible elements, variable width elements, and possibly more.

[ryan]

@ChrisB: Also, here's an example using Form Builder with embed option C in a responsive layout powered by Zurb Foundation (similar to Twitter Bootstrap): http://www.villasofd...landing-test-1/ … just in case this is helpful

[Biorn]

Well well Ryan.. thats more like it...

ok.. the markup is messy, but I can live with that now, so..

back to the formBuilder...

Thanks again..

[ryan]

Form Builder markup is going to look verbose relative to a singular-purpose form you'd create yourself. But verbose is not the same as messy -- it's actually very clean and optimized relative to the context. I've spent a good deal of time making sure that is so. That context includes everything from simple contact forms to giant application forms, while supporting nearly any kind of input type (known and unknown), in any possible layout, with any level of nesting. That's a whole lot of flexibility.

Think of a singular-purpose form as a propeller and a Form Builder form as a jet engine. Both are well optimized for their context. One is more complex than the other, but will take you much further and faster.

[interrobang]

At first I also wanted to complain about the verbose Form Builder markup. But the more I play with it, the more I like it. But I don't like the jquery ui themes, but the verbose markup makes it easy to use your own css most of the time.

One thing I don't like is how column width is handled. I would prefer having classes like width-50 instead of inline styles like style="width: 50%". And for some reason only the first column width in a row gets the value you set, The others are width-1%. For example having 3 columns (50%, 25%, 25%) is outputted as (50%, 24%, 24%) ?!

For using my own styles it would be nice if we could add a div wrapper around inputfields, like we already can with fieldsets. So basically I want even more verbosity

[apeisa]

I think the 25=>24 width is just to keep the 1% margin between fields. Of course that wouldn't be an issue if box-model would be used.

IMO hundred classes for different widths feels more cumbersome solution than inline widths. If you are gonna style the markup yourself, why not leave all the widths unset (does it put 100% then? I don't know) and style the widths and positioning with own css.

[interrobang]

Because I like setting the widths in the backend. But you are right I just can unset the widths and do this in my css. A wrapper div would be useful nevertheless.

I think the 25=>24 width is just to keep the 1% margin between fields. Of course that wouldn't be an issue if box-model would be used.

As the PW backend itself only supports IE>=8 I think we should change the box-sizing to borderbox and output the same width as we set in the column width setting. Shouldn't hurt anybody.

Having 100 classes feels cumbersome, but why not? It would make it much easier to customize the styling of the forms. Of course it would be a hack, but I could for example use a grid-system like zurb foundation with only 12 columns and map the class "percent-50" to zurbfoundations "six columns". Things like that are so easy when using sass/compass.

[ryan]

That's correct that the 1% is taken out and substituted as left margins instead. This is for all columns except for the first in a row.

I've actually been planning to switch to width classes rather than the inline styles that are used now. The primary reason is just to be able to support breakpoints with responsive layouts. For instance, if you've got a screen width under 600 px or something like that, you might want to cancel the floating behavior of all widths less than 100%, and instead just make them take up a full row. We can do that if we're using classes, but not if we're using inline styles.

@interrobang: Check the markup settings in the Form Builder module settings. This may let you add the extra wrappers you want.

Also want to mention that just because Zurb Foundation or Bootstrap (or another) provide some form features and grids doesn't mean that you have to use them with Form Builder. I personally think you are a lot better off with Form Builder's defaults than you are with those of Foundation or Bootstrap. Those frameworks are just trying to cover common form needs for the masses, but Form Builder goes well beyond this. As soon as you start letting a general purpose CSS framework take over your form styling needs, you are then limiting Form Builder's output capabilities to those of your framework. Though if you are dealing with fairly basic forms (primarily text fields) and simple needs, then there's also no harm in using a CSS framework for form styling either. But I think you will be happier if you give this control to Form Builder rather than [insert CSS framework here].

[renobird]

Hi Ryan,

Any chance you might might convert inline styles to class names in the near future? I'm using formBuilder on a site that has some large forms, and I'm stubbing my toe a little trying to make the forms responsive. I can override the inline styles at a specific breakpoint and make all the widths 100%, but that's a little heavy handed for some situations. 

[jordanlev]

Sometimes the system needs to serve the markup -- isn't this the whole point of ProcessWire's theme system?

What is it about forms that makes them not conducive to using custom markup? I am often in the same boat as the OP -- sometimes you just need to create a complex layout on a form or work within an existing CSS framework or style guide. And from what I can gather, it's pretty simple to do with PW's form builder. Here's an example:

<?php
$errors = $form->getErrors(true);
if ($errors) { ?>
	<div class="errors">
		Please correct the following errors:
		<ul>
			<?php foreach ($errors as $error) { ?>
				<li><?=$error?></li>
			<?php } ?>
		</ul>
	</div>
<?php } ?>

<form method="<?=$form->method?>" action="<?=$form->action?>">
	<?=$session->CSRF->renderInput()?>
	
	<label>
		<?=$form->my_first_field_name->label)?>
		<input type="text" name="label" value="<?=$form->my_first_field_name->value?>">
	</label>

	<label>
		<?=$form->my_second_field_name->label)?>
		<input type="text" name="label" value="<?=$form->my_second_field_name->value?>">
	</label>
	
	<input type="submit" name="submit" value="Save">
</form>

You could even "mix and match" automatic markup output of just some fields but not others, if for example you have a complex field type like a page chooser, by calling <?=$form->get('my_complex_field')->render()?>

   -Jordan

[Martijn Geerts]

@jordanlev for ProcessWire it is more important that all field values including notes, descriptions, headers, values and all other attributes can be manipulated even after they are created but before they are rendered. Markup is only important in the last process. ProcessWire form markup is clumsy if you wish to use it in an environment were it is not meant to be rendered like your front-end pages. But ProcessWire forms make so much sense when used in the admin area.

What you're doing here is for the markup way nicer, but inflexible if you change your form. I do think that there are possibilities to make your own logic, while looping the fields of your form.