Jump to content

Discussion: FieldtypeRockMarkup


Recommended Posts

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 ? 

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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 ? 

  • Like 2
Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

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 :-).

  • Like 4
Link to comment
Share on other sites

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!

  • Like 4
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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

  • 3 months later...

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 ?

  • Thanks 1
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...