oui_flat (rah_flat fork) - Manage templates and prefs as flat files

NicolasGraph · 2016-07-04 09:15:14

Textpattern community miss Gocom, but his plugins are still very usefull; in order to find a way to set custom prefs as variables with rah_flat I forked it and sent a pull request to Jukka a while ago — I included these changes in a plugin named oui_flat.

Unfortunatly, no reply, and no online activity on Jukka’s side (as most of you know); so, while he’s far from the community I recently decided to try my best to improve rah_flat and adopt it temporarily (hopefully, Gocom will come back and apply some changes to the original version).

I apologize for Composer users, but I don’t use it for now so I made the new version in a more usual way. If someone wants to make it work with Composer, just do it.

Now let me introduce you the last oui_flat.

Major changes are:

usual prefs are now hidden in the admin if set via flat files (like Pages and Forms tab…);
you can set custom prefs (visible or not) and use them as Txp variables;
forms are stored by types in subfolders (and you can still use custom types);
custom form types are changed to misc if the plugin is disabled or deleted (to avoid an error in the Forms tab);
textpacks support.

I hope you’ll like it…

Download | Documentation

Edit: It was test on Txp 4.6 but should work on 4.5.

Last edited by NicolasGraph (2017-06-05 15:32:58)

jakob · 2016-07-04 14:32:42

Excellent Nicolas! I’ve not tried it yet but I like the sound of your new additions. Can I ask a couple of questions / propose a few ideas?

You say variables set to private are user-specific (I guess that’s the user_name column in txp_prefs)? Would it be possible to make it role-specific instead, i.e. like in adi_variables where some are set by the admin and not accessible to staff writers etc.?
You’ve managed to recursively import forms from subfolders, which people have been wanting for a while! What might be (arguably) more useful, however, is to allow people to use arbitrary folder names, and then make the folder name part of form name, e.g. folder-name_form-name.misc.txp. That would get around the problem of forms with duplicate names. Your write “and you can still use custom types’ so maybe that is already possible?
How is this different from oui_flat, which I have already tried? Are they now the same? Are you retiring that?
You also have oui_prefs_functions. Does that work with this, and could you provide some examples of how to use it?

BTW: I made an attempt at a txp templates exporter (jcr_export_txp_templates) that exports pages, forms, prefs, variables, sections and styles (+ plugins) and matches (more or less) what you need for your previous version. You might want to fork that to match the input needed for this importer.

PS: You can actually use the modular plugin format that jukka uses with separate help and textpack files etc. without needing composer. You just need his plugin compiler to create the installer file. It still works fine.

NicolasGraph · 2016-07-04 15:28:34

jakob wrote #300175:

You say variables set to private are user-specific (I guess that’s the user_name column in txp_prefs)? Would it be possible to make it role-specific instead, i.e. like in adi_variables where some are set by the admin and not accessible to staff writers etc.?

Yes, that’s the user_name column. I don’t know if I can make it role-specific, but it’s a good question; i’ll check that.

You’ve managed to recursively import forms from subfolders, which people have been wanting for a while! What might be (arguably) more useful, however, is to allow people to use arbitrary folder names, and then make the folder name part of form name, e.g. folder-name_form-name.misc.txp. That would get around the problem of forms with duplicate names. Your write “and you can still use custom types’ so maybe that is already possible?

For now you can use any form type as a subfolder, native ones or custom ones (custom ones are changed to misc if the plugin is disabled) but, you are right, your form file names still need to be different for all forms but If I add the subfolder names to the file names you will need to use <txp:output_form form="type_form" />. Not so pretty… with for example <txp:output_form form="article_featured_article" />, no?

How is this different from oui_flat, which I have already tried? Are they now the same? Are you retiring that?

Yes, I deleted oui_flat and included it to the rah_flat fork. We probably don’t need two plugins for the same thing and I could change the plugin name if Jukka come back and don’t want to include some of my changes but pending that, it is mainly his code, so let’s keep the rah_ prefix.

However the version I introduced here have few more improvments (more options for variables, it hides flat prefs, etc.).

You also have oui_prefs_functions. Does that work with this, and could you provide some examples of how to use it?

I didn’t use oui_prefs_functions for a while and it should maybe release it but I can’t see why it wouldn’t work; oui_prefs_functions just provide some functions to use in the html value of prefs, where 'text_input' is often used. It allows to display a custom fields select list for example with 'oui_prefs_custom_field_list'.

BTW: I made an attempt at a txp templates exporter (jcr_export_txp_templates) that exports pages, forms, prefs, variables, sections and styles (+ plugins) and matches (more or less) what you need for your previous version. You might want to fork that to match the input needed for this importer.

An Exporter would be great, I thought about it but I won’t have enough time to do it for now (…do I have the skills?); thanks anyway for the link, i’ll take a look.

PS: You can actually use the modular plugin format that jukka uses with separate help and textpack files etc. without needing composer. You just need his plugin compiler to create the installer file. It still works fine.

Ok, I’ll see that too!

jakob · 2016-07-04 16:09:58

NicolasGraph wrote #300176:

but If I add the subfolder names to the file names you will need to use <txp:output_form form="type_form" />. Not so pretty… with for example <txp:output_form form="article_featured_article" />, no?

Actually I was thinking of a slightly different scenario. The developer would still include the form type in the file name (as was the case up to now) but could group forms however they wanted, e.g.

/teaser
  project.article.txp
  news.article.txp
  calendar.article.txp
/sidebar
  category-chooser.misc.txp
  author-list.misc.txp
  blogroll.misc.txp
  newsletter-signup.misc.txp
…

which would result in form names like this:

teaser_project
teaser_news
teaser_calendar
sidebar_category-chooser
sidebar_author-list
sidebar_blogroll
sidebar_newsletter-signup

or something like that. There are probably better examples and other organisational schemes, e.g. by content type – events, projects, blog – but the point is the developer could do it however they like.

I didn’t use oui_prefs_functions for a while and it should maybe release it but I can’t see why it wouldn’t work;

I haven’t tried it yet, but the idea is great – and just what MrDale had been looking for.

An Exporter would be great, I thought about it but I won’t have enough time to do it for now (…do I have the skills?); thanks anyway for the link, i’ll take a look.

jcr_export_txp_templates works already – try it! It’s basically just the export functions of mem_template adapted to match the format and naming scheme for rah_flat (i.e. including json output). There’s a switch in the code for using the newer/alternative naming scheme you used for oui_flat. All it may need is adapting to match your most recent revised naming scheme and extra prefs settings.

Destry · 2016-07-04 16:34:55

Maybe this facilitates getting flat-file management in Txp 4.7.x ;)

jakob · 2016-07-04 17:02:12

Other organisation patterns might be:

/event
  individual.article.txp
  list-item.article.txp
  nav.misc.txp
  pagination.misc.txp
  teaser.article.txp
/project
  individual.article.txp
  featured.article.txp
  grid-item.article.txp
  list-item.article.txp
  nav.misc.txp
  pagination.misc.txp
  teaser.article.txp
/blog
  gallery.article.txp
  media.article.txp
  poll.article.txp
  post.article.txp
  quote.article.txp

Here some forms have the same name but are in different folders. Another variant might be by BEM pattern:

/objects
  media.article.txp
  flag.article.txp
  list-item.article.txp
  picture.image.txp
  tabs.misc.txp
  accordian.misc.txp
/components
  slider.article.txp
  gallery.misc.txp
  carousel.article.txp
  related-articles.article.txp

Combine these with txp:article(_custom), txp:yield or rah_beacon and you get macro-style component code blocks.

NicolasGraph · 2016-07-04 17:22:34

jakob wrote #300179:

Other organisation patterns might be:

Assuming that you can import forms with the same name (but different types) how do you say to Textpattern which one to output?

Edit: oh, ok, that’s why you would like to add the subfolder name to the form name, isn’t it?

Last edited by NicolasGraph (2016-07-04 17:45:23)

mrdale · 2016-07-04 17:39:22

Personally, I’d prefer not to have to bake the form-type (which really has no real function beyond organization anyway ) into the filename… Much, much cleaner… and much less typing.

Consider this scenario.

You have a functional unit called “products”. You want to include forms you use for article calls and several other “worker” forms. When you work on a site’s “products” functions, you can then close up all other folders in your project and work on products… super clean.

products/
   product_list
   product_details
   product_gallery
cart/
   cart_list
   cart_scripts
   cart_ilage
maps/
   locations
   hours   
   addresses
   map_builder
common/
   frontside_edit
   page_nav

You can still use non-article form types as article forms, so the distinction TXP makes is pretty pointless… except I guess with the override form function which I never use.

NicolasGraph · 2016-07-05 06:25:35

mrdale wrote #300181:

Personally, I’d prefer not to have to bake the form-type (which really has no real function beyond organization anyway ) into the filename… Much, much cleaner… and much less typing.

I agree, it seems much cleaner to me too; and I think rah_flat was designed to use templates as flat files, reflecting the Txp organisation. In my mind changing this organisation is a core work.

You can still use non-article form types as article forms, so the distinction TXP makes is pretty pointless…

That’s Right…

NicolasGraph · 2016-07-05 06:26:32

Destry wrote #300178:

Maybe this facilitates getting flat-file management in Txp 4.7.x ;)

I hope so!

NicolasGraph · 2016-07-09 11:32:46

I reloaded my changes in a new rah_flat fork to keep the same files tree as Jukka and I added a support for Textpacks in the beta 2.

Last edited by NicolasGraph (2016-07-09 20:22:30)

NicolasGraph · 2016-07-28 11:18:50

In case you didn’t see it, I published a beta 3, adding a pref to choose which production status you want to use for auto template files upload. It can avoid, if set to Debug, to pollute your Testing Runtime.
Any feedback before the final release?

Textpattern CMS

Textpattern CMS support forum

#1 2016-07-04 09:15:14