I like the way linkedin.com and other website handle their labels: hide the label text and move the text inside the form field. Just check the search field on linkedin.com to see what I mean.

I adjusted this module so it would perform in a similar way. Find the patch attached.

Tell me if this makes a chance to be committed?

BTW the css placement of the label field didn't work for me, so thats why I wanted to enhance it.

CommentFileSizeAuthor
#14 compact_forms.zip4.12 KBtoemaz
#11 compact_forms.zip_.gz4.1 KBtoemaz
#11 compact_forms_input_value_5.patch16.58 KBtoemaz
#9 compact_forms_input_value_3.patch17.09 KBtoemaz
#6 compact_forms_input_value_2.patch17.69 KBtoemaz
#2 compact_forms_input_value_1.patch15.42 KBtoemaz
compact_forms_input_value.patch15.12 KBtoemaz
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

toemaz’s picture

toemaz CreditAttribution: toemaz commented
Category: support » feature

This issue makes more sense being a feature request, so I change the category.

toemaz’s picture

toemaz CreditAttribution: toemaz commented
FileSize
compact_forms_input_value_1.patch15.42 KB

I missed one thing: the input field value should be cleared on submit when nothing is typed in.
This is solved in this new patch.

Code optimizing is still possible. It's merely a proof of concept, but it is working.

toemaz’s picture

toemaz CreditAttribution: toemaz commented
Status: Active » Needs review

Damn, I forgot to set the right status: patch needs review.

tomsun’s picture

tomsun CreditAttribution: tomsun commented

Thanks for your input! Not sure I want to _replace_ the current behavior with your suggestion though - I like the idea of labels actually being labels... However, I'd consider including this if it is optional and controllable from the admin page - which is not a hard task to accomplish.

I have a week of holiday and sailing upcoming, will look at this again once I'm back.

toemaz’s picture

toemaz CreditAttribution: toemaz commented

Hi tomsun,

Thx for your feedback. Allow me to adjust the patch to make it optional and controllable from the admin page.
The reason I would choose this behavior is because the css didn't work out well, right from the deployment of the module. I guess other people might have the same issue and don't want to hussle with the css.

So, wait for me when I posted a new patch.

BTW I forgot to thank you for this nice module!

toemaz’s picture

toemaz CreditAttribution: toemaz commented
Status: Needs review » Reviewed & tested by the community
FileSize
compact_forms_input_value_2.patch17.69 KB

I modified the patch based on your advice and it very nicely integrated now.
Perhaps you may want to check the description added in admin form, whether thats clear enough (I'm not native english, so it is hard to come up with a decent short description).

tomsun’s picture

tomsun CreditAttribution: tomsun commented

That was quick Thomas! :--)

I have problems applying it though... If you scroll through the patch file, notice it removes everything and adds it back again, only now every other line is blank. Do you think you can generate a cleaner patch? If not, I'll go through it manually when I get back somewhere around Aug 19:th.

Btw, what is the reason for adding !important to the css file? This potentially gives themers a hard time.

toemaz’s picture

toemaz CreditAttribution: toemaz commented

I'll create a new patch. I think I used a different encoding in my editor.
I'll remove the !important as well. It was an artifact from some other code. Sure, it's better to remove it.

Thx for the feedback.

toemaz’s picture

toemaz CreditAttribution: toemaz commented
FileSize
compact_forms_input_value_3.patch17.09 KB

This time I created a new patch with Eclipse, and it resulted in yet again the same odd diff: - the original file, + the adjusted file. Strangely enough, this only occurs with the compact_forms.module and not with the js and css file. I'm not that a cvs wizard to create the patches manually, so this is the best I can do.
The previous patches were made with TortoiseCVS. The extra whitespace between each line came from TortoiseCVS check out. Again, it only occurred with the module file and not the other 2.

I have checked out lot's of modules before, and this is the first time I encounter these problems. Just to make it clear, it's only with the module file. Perhaps you can look into it because I might not be the only one having this problem.

Anyway, the new patch is attached, based on your previous comments. Speak you after the 19th!

Rob_Feature’s picture

Rob_Feature CreditAttribution: Rob_Feature commented
Status: Reviewed & tested by the community » Needs review

Is it just me or are these patches broken? (it definitely could just be me since I'm a patching rookie). I've tried to run all the patches above in OS X terminal using the patch command, and I get a different error for each one, with none of them resulting in a patched file.

Am I missing something? (changing to 'code needs review' since I haven't been able to patch successfully)

toemaz’s picture

toemaz CreditAttribution: toemaz commented
FileSize
compact_forms_input_value_5.patch16.58 KB
compact_forms.zip_.gz4.1 KB

I gave it a final try to end up with a decent patch. For compact_forms.css & compact_forms.js the patch seems ok, but for compact_forms.module I still can't get a decent patch. So, there is something strange with the module file, not with the others. Perhaps some character encoding? I can say this is the only module I have problems with when creating a patch.

Anyway, I have added a zip file with the full module (remove the .gz extension because drupal does not accept .zip files). So, you can test the module in case the patch does not apply. This is actually the module I use in production.

juliendorra’s picture

juliendorra CreditAttribution: juliendorra commented

I like the patched version a lot, as it offers both the original CCS-based and the Input value method. Testing them both is easy, and you can then choose you prefered way.

BUT, i stumbled upon a bug/quirk with the input value method :

On comment form, the default value is NOT replaced, and I end up with Anonymous (or any name I set for anonymous users, I suppose) in the field.

Which is not informative, of course :-) So maybe another option to override default input value would be nice. (in the meantime, I suppose I'll try to find a way via some theming method)

PS : by the way, will this patched version make it as 1.1 ??

juliendorra’s picture

juliendorra CreditAttribution: juliendorra commented
Status: Needs review » Reviewed & tested by the community
toemaz’s picture

toemaz CreditAttribution: toemaz commented
FileSize
compact_forms.zip4.12 KB

There is a new version of the patched module. It solves a very minor issue: sometimes the field value was not 'grayed' out.
Nevermind if this isn't really clear. Just use this latest version and let me know when it is ok. I can make a patch from it so it can be committed. It's already to long in the queue ;-)

juliendorra’s picture

juliendorra CreditAttribution: juliendorra commented

Thanks for the quick reaction !

Appart from the conflict with default values (in my case, I simply set nothing as the Anonymous users name, quick and dirty fix), everything seems fine. Note that I test it only on the comment form and user form for the moment.

I'll update with the new one as soon as possible.

jlndrr@drupal.org’s picture

jlndrr@drupal.org CreditAttribution: jlndrr@drupal.org commented
Status: Reviewed & tested by the community » Needs review

Hi, it's me again.

I just had a feedback from an user that he could not post comments : It seems that the patched Compact Forms erase the content of the form before submitting on firefox.

What is weird is that I think I tested it and it worked, but now it clearly doesnt work anymore. It must be a javascript issue. Some conflict with another module, maybe.

Anyway I switched back to the CSS overlay way -- Too bad because I like the label-becomes-value way more.

Any hints on how to make it works ?

toemaz’s picture

toemaz CreditAttribution: toemaz commented

My advice: use the firebug plugin for firefox to find out what goes wrong. Via the console, you could change the function of the form submit action in order to do some bug testing.

gausarts’s picture

gausarts CreditAttribution: gausarts commented

any update? Thanks

fm’s picture

fm CreditAttribution: fm commented

subscribing

omnyx’s picture

omnyx CreditAttribution: omnyx commented

has this been successfully resolved?
thanks

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Version: 5.x-1.0 » 5.x-1.x-dev
Status: Needs review » Needs work

@toemaz: Can you re-roll this patch against latest code in DRUPAL-5 or HEAD (for 6.x)? Your patch touched (and changed) pretty much everything, I just need the actual changes to review (and potentially commit). Thanks.

doublejosh’s picture

doublejosh CreditAttribution: doublejosh commented

subscribing.

I guess I'll install the zip and give it a test shot...

Well, that sucked. I didn't realize the zip is for D5. My fault, but Beware!

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Needs work » Postponed (maintainer needs more info)

Does this issue still exist after all? Due to recent changes, speed-ups, and other improvements I can't remember to have seen this faulty value overlay. If you test, please test with latest code in CVS, resp. the new dev snapshot of today.

toemaz’s picture

toemaz CreditAttribution: toemaz commented

@sun Sorry for my very late reply. I have not gotten the time yet to update the patch. Concerning the 'faulty value overlay', I created this patch mostly because I wanted it exactly as mentioned by a-list-apart: as a form field value rather than an overlay.

restyler’s picture

restyler CreditAttribution: restyler commented
Version: 5.x-1.x-dev » 6.x-1.x-dev
Status: Postponed (maintainer needs more info) » Active

I'm still having this problem with latest 6.x code. Is it possible to apply this patch to 6.x branch?

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

this issue persists and is causing an error in #542588: URL error on homepage field

I have been testing this module and I am getting the following error.

when the comment is submitted, Drupal displays the following message:

The URL of your homepage is not valid. Remember that it must be fully qualified, i.e. of the form http://example.com/directory.

It seems that when the homepage field is left empty, compact forms auto completes it using the label.
When i poked around in firebug, i got the following code:

<input id="edit-homepage" class="form-text error comment-processed compact-form-field" type="text" onfocus="if (this.value == 'homepage') {this.value = '';}" onblur="if (this.value == '') {this.value = 'homepage';}" value="homepage" size="30" name="homepage" maxlength="255"/>

I took a couple of screenshots to help anyone who is taking a look at this.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

tested this module with another drupal6 install and it worked fine. So the problem might be with my install or theme.

helloanshul’s picture

helloanshul CreditAttribution: helloanshul commented

I am a drupal newbie and have not applied a patch ever. Can you please suggest me how to use this patch?

toemaz’s picture

toemaz CreditAttribution: toemaz commented

Google is your friend

mstrelan’s picture

mstrelan CreditAttribution: mstrelan commented

If this gets in it should take in to consideration the HTML5 placeholder attribute. See #669878: Support for HTML5 placeholder attribute

BeaPower’s picture

BeaPower CreditAttribution: BeaPower commented

Has this been applied for d7?

jakew’s picture

jakew CreditAttribution: jakew commented

https://drupal.org/project/compact_forms