bernhard Posted April 9, 2019 Share Posted April 9, 2019 Not another Markup Fieldtype ? https://github.com/BernhardBaumrock/FieldtypeRockMarkup What do you think of a Fieldtype that does nothing else then rendering runtime markup from files that you provide in the settings or at runtime? In addition to that, I'd like the field to trigger javascript events to be usable for other fieldtype modules (like a charts module or a grid module). Javascript events would be necessary on field load (ajax/non-ajax), on collapse of the field, on click of a tab. When working with charts and RockGrid this has sometimes become a pain and I've implemented (sometimes dirty) fixes for that in different modules in different ways. I think it would make sense to have a solid base for such kind of modules (fieldtypes) that use some kind of standard events for standard situations. I'm especially interested in your opinions @Beluga because of the upcoming RockTabulator module and @kongondo because of your existing module. I think there are already similar modules by @Robin S and @kixe ? Thx for your input ? 2 Link to comment Share on other sites More sharing options...
dotnetic Posted April 9, 2019 Share Posted April 9, 2019 I only used the module FieldtypeRuntimeMarkup for now and it works, but has one big disadvantage (which maybe not applicable to all users): You can not use the runtime markup fields in a ListerPro to sort because PW is looking for a database table and throws an error. 1 Link to comment Share on other sites More sharing options...
kixe Posted April 9, 2019 Share Posted April 9, 2019 The idea of easy inclusion of any custom Javascript sounds good. The module I made and use is very slim and very stable. I use it extensively, especially with hooks and the full PW API and PHP. The only Javascript I have included currently is iframe resizer. 2 Link to comment Share on other sites More sharing options...
bernhard Posted April 10, 2019 Author Share Posted April 10, 2019 13 hours ago, kixe said: The only Javascript I have included currently is iframe resizer. What do you need iframe resizer for? Link to comment Share on other sites More sharing options...
Beluga Posted April 10, 2019 Share Posted April 10, 2019 I assume this would be for the admin. I have never used the other modules, but if you have experienced the need for something more, I'm sure it is sensible to build it ? Link to comment Share on other sites More sharing options...
kixe Posted April 10, 2019 Share Posted April 10, 2019 25 minutes ago, bernhard said: What do you need iframe resizer for? Keep same and cross domain iFrames sized to their content with support for window/content resizing, in page links, nesting and multiple iFrames. https://github.com/davidjbradshaw/iframe-resizer Link to comment Share on other sites More sharing options...
bernhard Posted April 10, 2019 Author Share Posted April 10, 2019 Thx kixe, I know that library, but I wonder where you have used it and what for ? Link to comment Share on other sites More sharing options...
kixe Posted April 11, 2019 Share Posted April 11, 2019 A customer wanted to provide own content from other sources in the admin. Videos and other stuff. Nothing special. Link to comment Share on other sites More sharing options...
elabx Posted April 12, 2019 Share Posted April 12, 2019 I'm curious, how would your module be different from FieldtypeRuntimeMarkup? 2 Link to comment Share on other sites More sharing options...
bernhard Posted April 15, 2019 Author Share Posted April 15, 2019 Hi @elabx, thx for asking ? On 4/9/2019 at 11:08 AM, bernhard said: What do you think of a Fieldtype that does nothing else then rendering runtime markup from files that you provide in the settings or at runtime? In addition to that, I'd like the field to trigger javascript events to be usable for other fieldtype modules (like a charts module or a grid module). Javascript events would be necessary on field load (ajax/non-ajax), on collapse of the field, on click of a tab. Well, one (crucial) thing would be the javascript events. Maybe that could be added to kongondo's module, that's why I was asking for his opinion. Besides that I don't like how his module works (I'm picky, I know). We had some discussion about it (https://processwire.com/talk/topic/10804-module-runtimemarkup-fieldtype-inputfield/?do=findComment&comment=148083). And it was simply easier to have things under my control than modifying his version with custom hooks. But yeah.. It might not be necessary to have another module for this ? 2 Link to comment Share on other sites More sharing options...
elabx Posted April 15, 2019 Share Posted April 15, 2019 8 minutes ago, bernhard said: But yeah.. It might not be necessary to have another module for this ? Well who knows! The devil is in the detail. And I do agree the javascript events would be a powerful enough reason. I also remember reading that conversation a while ago and do agree on your points. Particularly the "auto include" of files, pretty much like the modules. 2 Link to comment Share on other sites More sharing options...
kongondo Posted April 15, 2019 Share Posted April 15, 2019 Hi all, Sorry, I'm late to the party! Interesting conversation here. On 4/9/2019 at 10:08 AM, bernhard said: What do you think of a Fieldtype that does nothing else then rendering runtime markup from files that you provide in the settings or at runtime? On 4/9/2019 at 10:08 AM, bernhard said: and @kongondo because of your existing module. I am not a fan of duplicating modules, if what they offer are very similar. I would prefer to try a PR in the first instance :-). 3 hours ago, bernhard said: Well, one (crucial) thing would be the javascript events. Maybe that could be added to kongondo's module, that's why I was asking for his opinion. Besides that I don't like how his module works (I'm picky, I know). We had some discussion about it (https://processwire.com/talk/topic/10804-module-runtimemarkup-fieldtype-inputfield/?do=findComment&comment=148083). And it was simply easier to have things under my control than modifying his version with custom hooks. Interestingly, the other day when @adrian was reporting some issues with the module and suggesting changes, I had a rethink about your suggestions and decided it was worthwhile going with your suggestions, especially the auto include. I didn't mention it since I didn't have the time then to work on the module. So, my take is, we can improve the existing module, with new features and/or hooks. All PRs will be duly credited. I suggest we try that first. That's my opinion :-). 4 Link to comment Share on other sites More sharing options...
bernhard Posted April 16, 2019 Author Share Posted April 16, 2019 20 hours ago, kongondo said: I am not a fan of duplicating modules, if what they offer are very similar. I would prefer to try a PR in the first instance :-). 20 hours ago, kongondo said: Interestingly, the other day when @adrian was reporting some issues with the module and suggesting changes, I had a rethink about your suggestions and decided it was worthwhile going with your suggestions, especially the auto include. I didn't mention it since I didn't have the time then to work on the module. Well... me neither. I'd also prefer to have one common and stable solution, so if you are now willing to accept those changes (I also read the thread again and was confused by my own explanations sometimes. One point was misleading (that I was requesting to place the files in the module's folder which would break on every update, of course) and it's always a little hard to have such conversations via internen + non-native language ? ) I'll try to send a PR for your module as soon as I start working on the related modules! 4 Link to comment Share on other sites More sharing options...
kongondo Posted April 17, 2019 Share Posted April 17, 2019 21 hours ago, bernhard said: I'll try to send a PR for your module as soon as I start working Great. Give me a few days please to update the dev branch to include a few changes first, including the recent suggestions by @adrian. This way, we can work on one clean (dev) base. I'll also namespace it. Moving forward, we only support PW 3. 21 hours ago, bernhard said: on the related modules! I missed the memo it seems. Which ones are these? 1 Link to comment Share on other sites More sharing options...
bernhard Posted April 17, 2019 Author Share Posted April 17, 2019 35 minutes ago, kongondo said: Great. Give me a few days please to update the dev branch to include a few changes first, including the recent suggestions by @adrian. This way, we can work on one clean (dev) base. I'll also namespace it. Moving forward, we only support PW 3. Sure! Thx ? 35 minutes ago, kongondo said: 21 hours ago, bernhard said: on the related modules! I missed the memo it seems. Which ones are these? I'm talking about a new Grid module (or a Chart module or the like) that needs some javascript events to work: On 4/9/2019 at 11:08 AM, bernhard said: In addition to that, I'd like the field to trigger javascript events to be usable for other fieldtype modules (like a charts module or a grid module). Javascript events would be necessary on field load (ajax/non-ajax), on collapse of the field, on click of a tab. I think it would be nice to have some kind of base module that we can easily extend to our custom needs, but that does have some standards built in for things that can get complicated when building your own fieldtypes. I'm talking of all those tedious edge-case scenarios that make our lifes hard, like charts not updating it's size when resizing the window, grids not getting initialised when the field is loaded via AJAX, fields breaking when they are in a tab that is not shown on the initial page load. I think it would make sense to have some tested and reliable standard javascript events for all those situations. Or maybe I'm wishing something here that is not really possible? ? Link to comment Share on other sites More sharing options...
teppo Posted July 22, 2019 Share Posted July 22, 2019 Hey Bernhard! Just a heads-up that I've moved this older RockMarkup thread to the Module/Plugin Development area. Please let me know if you'd rather prefer to have it merged with the module thread – though if we merge it, posts here will probably show up before the initial post in that thread, so it may look a bit weird ? 1 Link to comment Share on other sites More sharing options...
bernhard Posted July 23, 2019 Author Share Posted July 23, 2019 Thx teppo, please leave it as is ? RockMarkup was released here: 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now