Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Javascript Panel
Bloke wrote #338682:
Why is everyone hating on the Styles panel?
It is not a question of hating on that Styles panel at all. I actually use it quite often for small stylesheets that cover particular (edge) cases.
etc wrote #338683:
[…] but rather handle it as any other mediatyped form. It would still be editable via txp interface and stored in db/fs. […] but I see no reason to handle css separately from other types (js etc).
That is my thinking as well, and when you the first post in the thread there is some demand for it. It could evolve in a panel that handle CSS, JS, eventually JSON scripts that seem popular, and also custom feeds (edgy case though).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Javascript Panel
Apologies. I misinterpreted “Would be nice to remove the Style panel”.
I’m totally on board with making it able to handle other types better.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Javascript Panel
Although I agree with the principle of mediatypes, I’m worried that the forms tab is already becoming too cluttered. As such the question is whether it is right to clutter it even more, or add mediatypes to what is now the Styles tab.
Thinking about it logically, forms are excellent for articles, shortcodes, and the other server-side php and sql type queries hiding behind our tags. CSS and JS on the other hand, are usually client side scripts for the website.
Their separation as such, could be semantic. Server versus client side.
Having said that, I seem to remember that a couple of years ago Oleg (etc), suggested that one way to make txp more flexible is to treat all text fields as modules that we could re-organise for the needs of the site. (Excuse the paraphrasing but I cannot find the actual post just now). This would be very useful, especially for the write tab, but I understand that unless we are careful we may lose backward compatibility which is essential for old sites.
In any case, returning to the issue of the Styles tab, moving it to the forms, would not make me lose any sleep.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Javascript Panel
colak wrote #338692:
Their separation as such, could be semantic. Server versus client side.
I agree that Forms pane becomes cluttered. Actually, mediatyped forms should be handled like Pages, but they are not tied to sections (save via themes).
I seem to remember that a couple of years ago Oleg (etc), suggested that one way to make txp more flexible is to treat all text fields as modules that we could re-organise for the needs of the site. (Excuse the paraphrasing but I cannot find the actual post just now).
Your memory is better than mine :-) Weren’t it custom fields?
Offline
Re: Javascript Panel
etc wrote #338709:
I agree that Forms pane becomes cluttered. Actually, mediatyped forms should be handled like Pages, but they are not tied to sections (save via themes).
A revamped Styles panel for what you call mediatyped forms, or what Yiannis (and I) client side content handling. The Pages model similar to the current Styles panel seems the more appropriate model. BTW, a stylesheet or script could be assigned (by the theme) to some section(s) or to some specific article(s).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Javascript Panel
etc wrote #338709:
Your memory is better than mine :-) Weren’t it custom fields?
I think that what the post was referring to was all fields in the admin side of txp including custom_fields, the body and excerpt fields, but also the fields that exist in other tabs such as the links tab and the files tab. The way I understood it then was that the separation of these fields was artificial, be it for functional purposes.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Javascript Panel
phiw13 wrote #338710:
A revamped Styles panel for what you call mediatyped forms, or what Yiannis (and I) client side content handling. The Pages model similar to the current Styles panel seems the more appropriate model. BTW, a stylesheet or script could be assigned (by the theme) to some section(s) or to some specific article(s).
Beyond js and css, we could add the construction of other client side types such as xml, rss, atom, and allow for anything else that may become popular in the future. The interface may be similar to the forms with accordion type separations.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Javascript Panel
Bloke wrote #338682:
I actually relish more admin-side control (e.g. being able to import/upload themes from a .zip file)
Offline
Re: Javascript Panel
Bloke wrote #338682:
I’d be stuck. I actually relish more admin-side control (e.g. being able to import/upload themes from a .zip file) rather than having to demand SFTP access in order to install a theme, or be forced to create each asset by hand in a new theme created from the back-end.
That would be great!
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline