Jump to content
Biorn

How to render a simpelt inputfield markup??

Recommended Posts

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...

Share this post


Link to post
Share on other sites

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 by teppo
  • Like 1

Share this post


Link to post
Share on other sites

!! hirvi hyppii kukku paivan !! :P

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..

Share this post


Link to post
Share on other sites

Sorry, its the inputFieldWrapper again.. :(

alot of markup..

Thanks for it anyway..

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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>";
}

Share this post


Link to post
Share on other sites

Ok..

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

I think I got it...

hmmm... module anyone.. :P

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.. :)

post-580-0-72075500-1348947867_thumb.png

post-580-0-51132100-1348947868_thumb.png

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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].

  • Like 2

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Tyssen
      I have a page that contains a single ProFields table field and I want to display the contents of the table on the front end and then for logged in users, they can edit certain columns in the table.
      What I have at the moment is
      $out = '<form action="'.$page->url.'" method="post" > <table class="table"> <tbody>'; $count = 1; foreach($page->fieldName as $row) : $out .= ' <tr> <td><input type="checkbox" name="fieldName_'.$count.'_columnName"></td> </tr>'; if($input->post->submit) : $page->of(false); $page->set('fieldName_'.$count.'_columnName', $sanitizer->text($input->post->{fieldName_'.$count.'_columnName})); $page->save(); endif; $count++; endforeach; $out .= ' </tbody> </table> <button class="button" type="submit">Save</button> </form>'; The two problems I have are:
      I get an error trying from $sanitizer->text($input->post->{fieldName_'.$count.'_columnName}), not sure how to make that dynamic.  If I change the above to just a static value, e.g. $page->set('fieldName_1_columnName', 'Testing') and save the form, it's not saving the values to the database. Where am I going wrong?
    • By Liam88
      Hi all,
      Quick question as I haven't found anything from my Googling. 
      I have a blog on the site which utilises pagination. On the standard blog page I have a custom header which has featured posts.
      Below that I then have recent posts like mosts blogs.
      Now if i click to page two or three I want the header to disappear and just show a continuation of the standard posts.
      I'm not sure how to go about this so any direction would be helpful.
      Thanks
    • By VeiJari
      Hello forum. I'm trying to figure out how to detect if current form has errors after saving it in pw admin page. This is so that our event location isn't added in database if we detect errors. But I can't seem to find a correct way to detect errors? I only found the wire()->errors() and it always triggers even if I don't have any errors. 
      How can I detect errors in a form?
      By error I mean $page->error('this is the red error');
    • By NorbertH
      As we are building some webapplications with the PW backend , having those really big spacings between all field elements in forms and everywhere is not too practical. 
      UI Kit already has less spacings between all elements than Bootstrap for example , but i am looking fore a more condensed BE Theme.  Maybe someone already made something like that?
    • By VeiJari
      Hello, our customer doesn't like the fact that they have to first add a title and then add the other info in the form. Therefore, we've enabled the way to skip this by making a temporary file before saving.
      But the problem is that by using module schedulepages in this piece of code in the module:  
      if (!$page->isNew() && $page->publishable() && $page->isChanged('status') && $page->is(Page::statusUnpublished) && $page->publish_from) {
                  $this->session->error($this->_("“Publish From Date” field was cleared to prevent the page from being unintentionally re-published on the next Lazy Cron run."));
                  $page->publish_from = null;
                  $page->save('publish_from');
              }
      it fires even with the temporary file and therefore after first save it resets the publish_from field. Is there a way to check if template is temporary, or something along those lines?
      One solution is just to ask the customer to first save the form after adding a title, but I don't see that as a good solution.
×
×
  • Create New...