Make the article form configurable

[victorjonsson]

Imagine that the article form in the list manager consists out of a set of fields. Each field can be described using JSON the following way:

{
  type: 'some-type',
  property : 'name', // name of article property (can also be an article option by prefixing with opt:)
  value : '', // The default value
  width: '100%',
  label : {
    text : 'Some label',
    display: 'inline' // Either inline or block
  }
}

The entire article form (that we have hardcoded today) could then be described by the following JSON:

[
   {
    type: 'image',
    property : 'image',
    value : '', 
    width: '100%',
    label : null // not relevant for image fields
  },
   {
    type: 'text',
    property : 'opt:preTitle',
    value : '', 
    width: '20%',
    label : {
      placeholder : 'Ingångsord',
      display : 'inline'
    }
  },
   {
    type: 'text',
    property : 'title',
    value : '', 
    width: '50%',
    label : {
      placeholder : 'Rubrik',
      display: 'inline'
    }
  },
   {
    type: 'slider',
    range : [10,100], // only used by slider
    property : 'size',
    value : '', 
    width: '30%',
    label : {
      txt : '', // No label for the font size slider
      display: 'inline'
    }
  },
  {
    type: 'editor',
    property : 'content',
    value : '', 
    width: '100%',
    label : {
      txt : '', // No label for the content editor
    }
  },
]

The streamer, settings and article connection would always be there but the rest would be configureable. This JSON-representation could be used by a javascript object (something like a ArlimaFormBuilder) to construct the article form.

This would give us the following benefits:

• Every website could have their own default setup for the article form (and the article object)
• Templates that support different stuff can have different fields
• File includes (that will be renamed to "article functions") can also use this for its arguments

[znoid]

I've thought about this too. Ever so often when you want to use arlima for anything else than relatively straight up articles you seem to end up using the provided fields in other ways they were intended, and you'd have to make up illogical rules for using the form ("Setting the font size to 20 will trigger an audio clip!"). Doing this the way you described would really open up a whole new set of possibilities.

onsdag 5 november 2014 skrev Victor Jonsson [email protected]:

Imagine that the article form in the list manager consists out of a set of fields. Each field can be described using JSON the following way:

{ type: 'some-type', property : 'name', // name of article property (can also be an article option by prefixing with opt:) value : '', // The default value width: '100%', label : { text : 'Some label', display: 'inline' // Either inline or block } }

The entire article form (that we have hardcoded today) could then be described by the following JSON:

[ { type: 'image', property : 'image', value : '', width: '100%', label : null // not relevant for image fields }, { type: 'text', property : 'opt:preTitle', value : '', width: '20%', label : { placeholder : 'Ingångsord', display : 'inline' } }, { type: 'text', property : 'title', value : '', width: '50%', label : { placeholder : 'Rubrik', display: 'inline' } }, { type: 'slider', range : [10,100], // only used by slider property : 'size', value : '', width: '30%', label : { txt : '', // No label for the font size slider display: 'inline' } }, { type: 'editor', property : 'content', value : '', width: '100%', label : { txt : '', // No label for the content editor } }, ]

The streamer, settings and article connection would always be there but the rest would be configureable. This JSON-representation could be used by a javascript object (something like a ArlimaFormBuilder) to construct the article form.

This would give us the following benefits:

• Every website could have their own default setup for the article form (and the article object)
• Templates that support different stuff can have different fields
• File includes (that will be renamed to "article functions") can also use this for its arguments

— Reply to this email directly or view it on GitHub https://github.com/victorjonsson/Arlima/issues/67.

Robert Sundelin VK Media AB Webbutvecklingschef [email protected] [email protected] 090-17 60 89 070-291 08 47 www.vk.se www.folkbladet.nu

[chredd]

This would indeed be a quite nifty feature. I can already think of a couple of times this would have been handy for us. +1!

[aaslun]

Nice suggestions for improvements indeed. As you mentioned, this approach would provide a greater (and intuitive) control over file include parameters. Perhaps allowing each parameter to managed through separate form inputs? Not having to pass them as a single query string would make it a lot less intimidating for the "non-developer"-users.

[victorjonsson]

I have actually already implemented this for file includes but I have not yet pushed it to the repo.

[victorjonsson]

Okey.. here's how it works with file includes https://github.com/victorjonsson/Arlima/wiki/File-includes

It's backwards compatible....

[znoid]

That is brilliant, my dear sir!

onsdag 12 november 2014 skrev Victor Jonsson [email protected]:

Okey.. here's how it works with file includes https://github.com/victorjonsson/Arlima/wiki/File-includes

It's backwards compatible....

— Reply to this email directly or view it on GitHub https://github.com/victorjonsson/Arlima/issues/67#issuecomment-62679585.

Robert Sundelin VK Media AB Webbutvecklingschef [email protected] [email protected] 090-17 60 89 070-291 08 47 www.vk.se www.folkbladet.nu

[chredd]

Indeed brilliant!

[aaslun]

Awesome!