yellowled

I ended up using this script: http://webcloud.se/c...ery-Placeholder and it does exactly what I needed.

I have never used that particular one, but just from experience: placeholder polyfills can behave erratically in some form environments. Some of them use relative/absolute positioning to overlay the input element with a span which can have various side effects depending on the rest of the CSS. So always make sure you test this properly, it can come back and bite you.

As always, all this depends on which browsers you have to/want to support. Then again, if you don't have to support old IE, polyfills are usually not necessary in the first place.

That will probably perform a search with the search term "Search" if somebody submits the search form without having entered actual search terms. This is not always desirable, and it does not happen if you use the placeholder attribute. (Just sayin'.)

which works in most up to date browsers (but I think not IE9, although I haven't checked recently).

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.

Netcarver,

thanks, I appreciate it. Looks pretty straight-forward, even for a non-coder like me. ;-)

Thanks for pointing that out, I didn't stumble across that with my previous forum searches.

I'll very likely only need forms submitted via email for the time being. The site will likely have a standard contact form plus another one with some extra fields which is basically an extended contact form. Nothing fancy. I also don't need a form builder, I'm comfortable building the form's HTML myself. I'm just not a PHP coder myself, so writing the script to process the form myself is not an option. But any formmail script out there should suffice, I would just prefer a built-in solution.

I am sorry for having to ask this. I know developers hate to be bugged about a schedule for new features. Sorry.

The roadmap lists built-in support for forms for PW 2.3 which is scheduled for May. I have a project coming up which is due at the end of June, and I'd very much like to use PW for it. However, it will require a few forms – nothing too fancy, probably just some formmailer stuff.

Will PW 2.3 definitely have built-in support for forms? Is there a rough estimate as to when it might be released?

Then again, I could as well go with PW 2.2, use any external formmailer and switch to the built-in form processor later. Which raises the question how easy it's going to be to make that switch.

Personally, I think I prefer to use PW's API as far as possible (which seems to be pretty far). The reason is simple: As soon as I'd need extra PHP code beyond the very basic stuff needed with PW's API, I'd be lost. For me, PW's API really does work like jQuery in the ssense that it gives me an easy-to-use "layer" and spares me having to really use the language "below".

Also, I think it's confusing to still think in the terminology of any other CMS. I really don't know MODx that well, so I'm perfectly happy to "think in PW terms".

You can of course have data as pages that will get displayed through other pages. One way to display it is using code in the page template that will render the data, so in the foreach you have something like a markup generating code. FOr example often used is something like this.

I was aware of that – but that way, the template code is added to the parent's template file, which is fine and very flexible, but kind of confusing to me at times since I've never used a CMS before which does it that way.

Another possibility would be to have a member.php that will contain the markup and then can be rendered using the $page->render();

Ah, so that's what $page->render(); is for – it renders (in baby developer's talk – I'm not a skilled PHP coder) a page according to the template assigned to said templatepage, but maybe in a different context? That's smart.

As I tried to say before – it all makes sense and gives users great flexibility, it's just a bit confusing sometimes if you're used to other systems.

Hi everyone.

So far, I love PW. Now, before I start using it in more than some get-to-know-it projects on localhost, I'd like to make sure I understand in properly.

1. So everything is a page, right? Not only every piece or group of text or data I want to display in an actual page, but also stuff I might want to pull into a page is supposed to be put in a separate page – like news items, blog articles, events, staff members etc. Or should certain types of data actually be stored in a different kind of way (XML or JSON comes to mind) to make it easier or more performant to process?
   
2. Let's say I have a page which contains some fields, but it's not supposed to be displayed as an actual frontend page. It only exists to store those fields and will be referenced in an actual page, mostlikely its parent.
   My "natural" way of approaching this would be to assign some kind of "snippet" template to the page containing the content, i.e. the markup which it should have in the parent page. But that doesn't seem to be the way it's supposed to be handled in PW, at least I haven't found a way to do "insert $page here with the markup assigned to it in its template".
   This does make sense since it gives me more flexibility to emit the same data with different markup in different context. However, in some cases where I don't need that, my "natural approach might be easier. Is there a way to do that?
   

Hope this makes sense.