Hi

I'm the developer of maxlength_js. By the time I started writing the module this one didn't have a D7 (or I missed it), same with other mdoules (listed on the maxlength_js page) that do not have a D7 release, so I decided to write one that was generic enough to work with any field.

I haven't tried this one, so can't comment on it. But since it is encouraged avoid duplication of efforts, I come here to see if we can join forces to leave just one module.

Maxlength_js basically tells you how many characters you have left on a field, and works with ANY text field, and can be extended to work with pretty much any field. It integrates with the Field API to do so. It is not node specific.

Modules who create their own forms can use the #maxlength_js property to activate the JS on their fields.

I recently managed to get it working with TinyMCE and CKEditor using the WYSIWYG module. Other editors can be integrated.

Hope you all have a great day.

Cheers

Comments

dawehner’s picture

Since a short time there is an API to set #maxlength to each field as well, but this isn't ported yet to drupal7.

I'm the developer of maxlength_js. By the time I started writing the module this one didn't have a D7 (or I missed it), same with other mdoules (listed on the maxlength_js page) that do not have a D7 release, so I decided to write one that was generic enough to work with any field.

Everytime i read this i don't get it ... why didn't you ported the module and made it more flexible.

I recently managed to get it working with TinyMCE and CKEditor using the WYSIWYG module. Other editors can be integrated.

That's a really nice feature.

Did you see any other differences between the modules? In general i think #maxlength also afaik works php validation ... does your do this as well? If yes why not move your module to a new branch of the maxlength module? Maxlength seems to be a better name as maxlength_js.

jm.federico’s picture

Hello

The reason I didn't port one was because of the way things were done, the fact that a module exists, doesn't mean it can be ported, and sometimes it is just better to open a new project.

#maxlength_js works php validation too, the thing is you need to set both, the #maxlength property (numeric value) and the #maxlength_js one, (boolean). You might want just some of the fields to have the counter, so setting #maxlengt shouldn't force the counter to show up. PHP validation is performed but not by maxlength_js, itjust works with textfields and textareas by default.

I agree maxlength is a better name, and now that I think about it I couldn't come up with a reasons why I went for maxlength_js.

If it is OK with you, maxlength_js could be a V3 branch for maxlength.

dawehner’s picture

The reason I didn't port one was because of the way things were done, the fact that a module exists, doesn't mean it can be ported, and sometimes it is just better to open a new project.

That's actually not an argument ... i could easily choose the same argumentation to get that you should have ported the original module :)

Anyway, i took some time to read the code of maxlength_js... this is really a damn small effective module. Thumbs up!
Would you accept to be another co-maintainer of maxlength and rewrite it for 7.x to make it more flexible?

In general perhaps some of the settings have to be added back from maxlength-2.x but this shouldn't be impossible.
For example you could enable maxlength on titles, not sure whether a lot of people use this.

jm.federico’s picture

Yeap, I'll be happy to join the party!

One question though, what do you feel should be the path to choose: get maxlength_js as it is and add functionality that is not covered by what it already does? Or try to add what it does to maxlength.
As I see it the main missing piece from maxlength_js, which you mentioned already, is the title, because apart form that it can be enabled for any field that uses the field API, and can also be added to any field via code.

Could you make a list of the functionality you think should be kept from maxlength, which is not covered by what maxlength_js does? This would help me a lot to make a working plan.

And, thanks for the thumbs up!

Schnitzel’s picture

Just adding myself to the subscription :)

One of our employees and me wrote the Port to D7 of Maxlength, we had to port the module for a customer, the D7 Port is now in a state where it needs more testing, especially the comments make some problems and also the integration with WYSIWYG is not yet done.
We had quite busy months, so we didn't had too much time to make the port to a stable release.
Now just before we started with some more development you came up with the other module.
I also think that we definitely should combine the forces!

I just went a bit trough the code and these is a short list of features I see in maxlength with are today missing in maxlength_js (but not really complete):
- counterText definition per Field (also possibility to print the maximum and the actual count in the counter text)
- Node Title Handling (important to also check if the title module is used, which changes the title to a normal field)
- Exporting of configuration (We kept the variable_set way to save the definitions per field to be able to export the settings via strongarm, I'm not 100% sure but as far as I can see, this is not possible with maxlength_js, but maybe we should extend it with exportables module)
- exceeded checks (or is this already properly handled by #maxlength from FAPI?)
- nonJS Functionality (maxlength shows you the information message about the limit even if JS is not enabled)
- possibility to make the counterText as a #prefix (well not really handled by maxlength itself, but we fixed this with an easy custom module, which moves the #suffix to #prefix)

@dereine I let you decide which is the better way to do it: adapt maxlength with functionalities from maxlength_js or the other way. My personal opinion is, that maxlength has too much stuff from D6 (CCK) in it and the maxlength_js is a very effective. Or maybe this discussion isn't really necessary ;) But I +1 for keeping the name maxlength and make a 3.x Version and making maxlength_js obsolete.

Cheers!

dawehner’s picture

Yeah maxlength_js is really how a flexible module in d7 should look like.

@Schnitzel
The d7-2 version currently lacks some features relative to d6-2, especially a more flexible api.
I'm not sure it is worth to work on it, if the "official" maxlength version will be d7-3 in the future.

Schnitzel’s picture

Yes I guess you are right, we should work with maxlength_js

What do you suggest, should we open d7-3.x branch and let jm.federico work as maintainer?

Cheers

dawehner’s picture

Seems to be fine from my perspective. As long it's not the suggested branch everything is okay.

@jm.federico
Welcome to the module with the most maintainers compared to the amount of code.

jm.federico’s picture

Thanks guy. Happy to join the crowd!

Will commit the initial code in a few days!

Cheers and happy coding!

jm.federico’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev

Changed version to new branch.

Clssing issue

Opened new one for upgrade path #1255488: Upgrade path to 7.x-3.x

jm.federico’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.