Jump to content

bfncs

Members
 View Profile  See their activity

  • Posts

    133

  • Joined

  • Last visited

 Content Type 

Everything posted by bfncs

  1. bfncs
    Just read through all of your discussion about better and more documentation/tutorials and I think that this is really great and I can't wait for all of this to start! Also, I hopefully get to volunteer in writing a tutorial or two, just to give back. There's just one thing (aah, it had to come), that I'm not really fond of, and it's the "sell" thing. While I think it's perfectly ok to publish a book and earn money with it, I would favor if this effort would be put in some freely (in the sense of beer and thoughts) available product - especially if the works comes from the community itself. Not so much because of the money involved, but much more to get this out to everyone interested. I would also support the urge to get this out on dead trees, since this is something nice to have, but I'd really appreciate if there would be an open online version of it. That being said, I really like the ideas about the book structure, this might be the right thing for a lot of beginners. Might be a good place to throw a link to the CakePHP Cookbook into the discussion, which greatly accomplishes the job of being readable from top to bottom and also serve as a highly interlinked reference. Edit: Oh, while this thread really drifted apart, I'm still interested in discussion of the nonexistent isPublished() method.
  2. bfncs
    Hey Matthew, first, thanks a lot for testing and using it, I'm always glad if something is helpful to other and to get back feedback from it! What you're pointing out there is something that I had in mind, too: the one activating the functionality for a field is usually a dev and should know what he or her is doing (i.e. don't add the counter for WYSIWYG textareas). Since you literally have to enter limits for every single field you want to use this with either way, the practical implications of the current behaviour shouldn't be too critical. On the other hands: minimizing the chance for something to go wrong is always something to go for, assuming that the user will know what to do is never an execuse. Also it's tedious, to have to look up things in the documentation of each single module you use, even for the simplest things (reminds me of MODX the bad way...). The discussion is also interesting, as this is a pattern that might be used by others modules, too. It would be great to have a working example for building this kind of field modification module (with validation and interactivity) using best practices that can be used in other places afterwards. Just thinking out loud here, wouldn't it be possible for the Inputfield class to have a function isPlaintext() or even better to add an interface InputfieldHasPlaintextValue that modules with plain text values (no markup, no WYSIWYG, etc) would implement? On the one hand, this would make it easy in this case to check, whether the module is applyable and might be useful for others. On the other hand, I like that Pw isn't bloated with stuff like that myself, starting with this, where would you stop... I'm leaning towards implementing Ryans proposal to have a module setting for this now. This should provide sensible defaults for all core module Inputfields and make it possible, to add the functionality to all derivates of InputfieldTextarea later. Tinkering with it when you're only using the basic functionality and nothing else wouldn't be necessary that way, but it still would be possible to add the functionality for all super custom fields you add later. In the module settings, this should be hidden enough for good I think.
  3. bfncs
    The problem with derivates will occur, if someone adds another module where the counter doesn't fit in to InputfieldTextarea (like with TinyMCE). This won't break anything directly, because the counter only comes to action if you enter limits in the field configuration, but still this is something making it possible to do something wrong (and maybe don't get why). The simplicity of if($field != "InputfieldTextarea") return; is a good idea to prevent this. On the other hand this will also prevent adding the counter to derivates of InputfieldTextarea where it actually would make sense. The same is true for making it as a distinct field, because it wouldn't allow to add functionality with modules working with InputfieldTextarea hooks only, even if it makes sense. Ryans proposed solution with a config setting to select on which variants of Inputsfields this should act would be the most flexible solution, but on the other hand, Soma, you're right about options everythere, this is really overcomplicating things for the clueless user. I think all different methods mentioned here have their pros and cons, I'm not really sure, which one would be the best way to go. Maybe there are even more options?
  4. bfncs
    Ryan, thanks a lot for looking into this, your feedback is very much appreciated! You're raising a really valid point there, I didn't really think about problems with other derivates, but you're completely right. I think this should be approached before submitting to the modules directory because depending on the solution, it might block the easy update path for some users later. I'm not so shure which of your proposed solutions, that all sound reasonable, is the way to go here. Thus my question about the module as an input field itself: would there be any problems for a user to change from a normal InputfieldTextarea to a InputfieldTextareaCounter and back? If this is trivial (as it looks to me), I think this might be the cleanest solution to do it. Otherwise I like the checkbox solution second best, but it requires more configuration knowledge (I already see the "Why is my InputfieldXY behaving strangely?" thread in front of my mental eye).
  5. bfncs
    Thanks Ryan for shedding some light on this, that was really helpful! I think both methods, with Inputfield::processInput() as well as with the setAttribute() method make perfectly sense, the latter being the more stable one from what you said. I still think, that it would be great to have validation a little more obvious, but from everything I read, this is already a medium term target, which is great!
  6. bfncs
    Hi Matthew, this shouldn't have anythind to do with the module itself, but you might try the following: Delete everything related to the module from your /site/modules folder. Use PHPMyAdmin or something similiar to look in the "modules" table of the database. Delete the entries named "TextareaCounter" or "TextAreaCounter". Delete all files starting with "Modules." from your /site/assets/cache folder (ah, forgot this at first post...) Install again as usual. I haven't tested this in any way, but his hopefully helps. Edit: Sorry to cause you problems with the rename, I just thought it would make more sense with the lowercase "a"...
  7. bfncs
    Hey Soma, thanks for pointing it out, you're totally right, this one slipped through. I quickly changed this to be $inputfield->error(sprintf($this->_("Too many %s"), $type));
  8. bfncs
    Hey Soma, after reading again and this time more thoroughly through everything you wrote and linked to I have the feeling I made a bit too much of a problem out of it, because you're totally right with that everything is already possible. The code you posted really helped here, thanks again! To solve the problem with saving was also pretty easy: just doing a untrackChange('value') in my hook after Inputfield::processInput was everything needed (see here).
  9. bfncs
    Hi Matthew, thanks a lot for your quick feedback, this is very much appreciated! Strange, so it looks like the JS isn't loaded/doesn't work, but it certainly does for me. How did you update the code? The name changed from "TextAreaCounter" to "TextareaCounter", so the folder has to be renamed to "TextareaCounter", too, just a quick guess that it might have to do with this. If this doesn't help: can you check whether TextareaCounter.js is loaded and whether there are any JS exceptions in your browsers' console? If you find any error messages there, please just paste them in here. With kind regards, Marc
  10. bfncs
    Hi everyone, I just worked on this a little and added client- and server-side validation. It would be great to get some feedback on this, so if anyone has some time to do testing, please check it out here: https://github.com/boundaryfunctions/TextareaCounter If there are no crucial bugs coming up for you, I'm going to submit this to the module repo soon.
  11. bfncs
    Ok, I just pushed this to a real repository: https://github.com/boundaryfunctions/TextareaCounter Please file a pull request when everything's working, that would be great!
  12. bfncs
    Ah ok, I somehow got you wrong in that you wanted to point out that server-side validation wouldn't be necessary, please don't mind! Your work on No. 1 is very much appreciated. Maybe your or I or someone else should put it in a complete github repository...
  13. bfncs
    Thanks for pointing this out, I did read what Ryan said about this and also I know, that I'm not the first one missing this. That's just why I'm writing: it just seemed like there wasn't any clear plans and I wanted to stress that I would appreciate to see this in core a lot. Oh, this is really helpful, must have overlooked it... sorry. I'm still going to play around with Fieldtype::___savePageField(), looks like the right place to try this at the moment. Just need to conjure up some more time first... edit@interrobang: I just read your answer after posting, really helpful though. I already read about the regex support in the dev branch. Didn't try it already, but it is certainly a very nice addition. Still, what I was going for was more targeted on something else, namely a good structure in the API to hook custom validation with all bells and whistles in simple modules. Especially that bit about "saving when it doesn't validate" is something I want to get around. This is something that works the other way around in most other frameworks/cms/cmf I know so far by default and it always made sense to me.
  14. bfncs
    Hey Matthew, I'm totally with you about the immediate-response-thing, that's absolutely something that has to be there. You already posted some links to jQuery plugins that do this yourself, they all work basically the same way: on every interaction with the input, check whether the limit was reached and if it was, cut away all characters beyond the limit. Since the rise of HTML5, there's the maxlength attribute, too. While this is all nice and therefore should and will be used, client-side validation can never substitute server-side validation. I know, that in the normal use scenario, you only have accredited users on the system that don't want to do anything nasty with it, but still: you may always have a Javascript error somewhere else that prevents your validation code from execution, Javascript may be switched off, the maxlength attribute isn't supported in older browsers, everything that can possibly go wrong will go wrong, everything that can't go wrong will almost certainly go wrong, and it would be nice if this would module could be used safely in all kinds of frontend forms, too (because it probably will the sooner or the later). All of these are imho good reason to do server side validation, even if you don't expect the evil user.
  15. bfncs
    Thanks a lot Soma, amazingly quick and helpful as always! I already skimmed through most of these threads which are really informative, but wasn't really pleased with what I found there. I'm really hoping that there's some more structure coming to validation in Pw. While I can understand, that it doesn't fit Pw's philosophy to trash default Inputfields up with all kinds of validation possibilities, it would still be great to find preparations for validation in the API so it can be easily implemented by non-core modules. I have something in my head that might be roughly described as some kind of interface on Fieldtypes where you can hook into, have the variable passed, do your checks and return some ValidationResult object including things like: Was the value validated? (true/false) If not: an error message (localizable) Should the value still be saved (true/false) Also an array of ValidationResults to show multiple validation errors would be needed. This can be evaluated before finally saving the field then. Is this understandable and does it make sense for you? I imagine, that it should be possible without forcing anyone to use it but making it easier to use than now.
  16. bfncs
    Hey apeisa, thanks a lot for the quick reaction, this really helped a lot, that pointer to how it is done with "required" in particular, didn't think of it before. As I see it in InputfieldWrapper::__processInput(), if required fields are empty, the Wire->error() method is called to produce an error notice, and that's it, it's still saved to the DB (or did I overlook something while grep-ing through the core?). While this might be ok for most use cases (with sanitizing before outputting it), I don't think that this should be the only means of validating here. Imagine you want to validate for a certain string length, your user has entered something before that was short enough and now expands over the length limit and saves. He now ends up with a new string in the DB that is too long (and probably gets shortened uglily on the front end) instead of his old string that fitted the limits. I think it would be at least desireable to choose, whether you want to store or keep the old value, when validation doesn't work. In my opinion, this definitely is something that should be thought about since validation might be one of the core needs of part of the target audience of Pw. To get around the practical problem, I now think the most comfortable way might be to hook before Fieldtype::___savePageField(), as this is exactly the place, where the field is going to be saved. This makes more sense to me than to hook to page save where it has to be called on every page, even if the fieldtype to be validated isn't included. In the hook, it should be possible to throw a visual notice and prevent the saving. Is there some explicit way to stop the hooked to method from a prehook? Else a workaround would be to just set the field's value to the default value. I'm going to try this later, not enough time for it now. Still, any help on this is appreciated a lot.
  17. bfncs
    Didn't see any flippancy there, no worries On the contrary, I'm really appreciating how much work a lot of people put in the community here!
  18. bfncs
    Hmyeah, but where is the wiki section for desired new features? Or would it be better to post in the Whishlist & Roadmap subforum? I was just asking because there was no feedback from Ryan so far, so probably it's ok to just wait. I'll definitely ask for a wiki account when he's back, thanks a lot for pointing this out.
  19. bfncs
    Hey Soma and Joss, both of you are pretty right! As you may have noticed, I'm still pretty new here (coming from mostly MODX and CakePHP), so I hope you can understand that I'm eager to spread the word and convert more people to this beautiful system! I think the wiki is the right place for this as it already has categories for Short and Long Tutorials. I'm definitely going to work on something to go there in the holiday season at the latest. What do we do now about Page::isPublished()? Edit:
  20. bfncs
    Hello everyone, I'm currently working on a simple module (view this thread for more details) and ran into some problems with the validation of input data. I did some research, but I wasn't able to find answers to these questions: 1. If you develop your own Inputfield/Fieldtype module, where do you do validation? I've seen other modules do it in Fieldtype::sanitizeValue() (apigen), but this seems rather strange to me. Also, as far as I got it, they didn't throw any errors back to the user but just quietly changed everything, that doesn't make sense without the user knowing it. This leads to the next questions: 2. What is the correct way to get visual validation error reports to the user? 3. How to prevent a page from saving with validation errors? With this fairly basic stuff (where I wasn't really able to find something meaningful about) out of the way, what I really want to know is this: 4. How do you add validation with error reporting to an existing Fieldtype module? I want to add my custom validation with error reporting to the standard FieldtypeTextarea module (only when some conditions are meet in the corresponding Inputfield for sure), but I have no clue what would be the way to go there and wasn't able to find any module that does it like this. Please shed some light on these question, would be very much appreciated! Marc
  21. bfncs
    Hi Matthew, thanks for testing and doing research! I'll definitely add some means of limiting the input clientside, but I also want to validate this clientside. I know, that the inputfields should have to deal with thrusted content only, but still, I think it is a question of good coding style to validate everything serverside as well, just to be really sure. I looked into other modules to see how they do it, and it looked to me, that all of them do their "validation" in Fieldtype::sanitizeValue() (apigen) and without throwing any errors. Is this really the proposed way to do this? This seems really strange to me, why is there no Fieldtype::validate()? Even if this is the way to go: Fieldtype:sanitizeValue() isn't hookable, so how could I slip my own code into FieldtypeTextarea then? Can someone please shed some light on this? Edit: Since I think answers to these questions might prove helpful to others as well, I opened a new thread in the Module Development Forum, asking the question a little more generalized. You can find it here: http://processwire.com/talk/topic/2365-validation-for-own-inputfieldfieldtype-modules/
  22. bfncs
    Hey Matthew, you're welcome. Thanks for the feedback and you're right, most oft the credit goes to Soma. This isn't in the Moduls repo for now because I wanted to get some things right in the first place, but I hope it's going there soon. I did some searching but didn't really solve this problem, so I hope someone can give me a pointer on this: where would I hook to do some custom validation for my input field (including error reporting)? Any help is very much appreciated.
  23. bfncs
    No offence intended, it's just funny how this thread evolved. I'm still thinking that it might make sense to start a new thread if some people want to put some shared effort in producing nice tutorials - still don't know where to open it though. Hm, just wondering what the benefit of a multitude of system states opposed to fields would be? I mean: what would you be able to do with system states, that you can't do with normal fields? Edit: oh, sorry... I completely overlooked the second page ;-)
  24. bfncs
    Hi there again, wow, this thread really wandered of to some completely different topic that is more interesting though. I like the aim for publishing more and better tutorials for Pw, this should really be done! Why don't we open a new forum thread for this (but in which subforum?), make a roadmap for possible tutorials where everyone can volunteer to write one? While still being new here, I'd definitely contribute, and it looks like some of you would like to give back this way, too. If this turns out, that we can get a decent amount of tutorials, these might be published outside of the forums afterwards, to make them more accessible. It would also be nice to work on something like a guideline for tutorials to make them coherent. What do you think about this? On the topic this thread was about originally, I can only repeat that imho Page::isPublished() would make sense, but I'm also completely ok with not doing it if the risk of entering a slippery slope of more and more convenience wrapper methods that trash up the API is too high here.
  25. bfncs
    That's not very creative, but: 3x +1
×
×
  • Create New...