The direction of Textpattern 5

hcgtv · 2011-02-18 15:14:19

Algaris wrote:

How about a WYSIWYG editor that outputs textile? That way if you turn it off you’re just left with the textile markup.

rah_textile_bar comes to mind, maybe updating it with all that you can do with the new Textile library that is being worked on?

hakjoon · 2011-02-18 15:26:21

Algaris wrote:
How about a WYSIWYG editor that outputs textile? That way if you turn it off you’re just left with the textile markup.

I keep wanting to build this into hak_tinymce. I need to sit down and figure out the html->textile part.

I’d love to see the text processing pieces be pluggable. After all textile is a separate project now so it would be nice to plug in markdown etc in there. This would also allow for textile enhancements outside of TXP releases.

Algaris · 2011-02-18 15:50:33

I’ve tried rah_textile_bar in the past. The main problem for me is that when I want to insert an image or a hyperlink it pops up so many different windows asking me to type in address, alt text, etc. hak_tinymce on the other hand brings up one image window that allows me to browse and select the image I want and input the alt text, etc in one go.

That would be a nice enhancement to your plugin hakjoon.

Last edited by Algaris (2011-02-18 15:52:38)

maverick · 2011-02-18 16:12:06

hakjoon wrote:

I need to sit down and figure out the html->textile part.

wouldn’t that make it — wysiwyg -> html -> textile -> html — ??

maverick · 2011-02-18 16:21:45

Algaris wrote:

I’ve tried rah_textile_bar in the past. The main problem for me is that when I want to insert an image or a hyperlink it pops up so many different windows asking me to type in address, alt text, etc. hak_tinymce on the other hand brings up one image window that allows me to browse and select the image I want and input the alt text, etc in one go.

Related by tangent. I’ve found situations where I wished wet_quicklink could work with the other content types (links, files and images) as well. It would create a generic “Insert” option in the left hand menu. Combined with rah_textile_bar, it would meet most of my needs for in-article insertion.

Alternately, if bot_image_upload and bot_file_upload could have an option to insert a link in the article body, that would also get most of the way.

hakjoon · 2011-02-18 19:39:41

maverick wrote:
wouldn’t that make it — wysiwyg -> html -> textile -> html — ??

Yes. The idea was that you could process content on save from tinyMCE back into textile. When you loaded it up you could pull the body_html value to edit. It’s a bit round about but if you want to keep stuff in textile it would give you a real wysiwyg.

I personally just use an admin version of hak_textile_tags I built ages ago. The same functionality can be had with Mary’s upm_quicktags and my textile implementation for it.

rah_textilebar worked differently in a slight way that I didn’t like, and since I had something written already I just kept using. New users would probably be better of with Jukka’s work.

mrdale · 2011-03-02 17:27:47

Just want to weigh in on “pages” & “forms” being merged into “templates”.

While I’m not afraid of drastic changes to the core of TXP, I think we need to really focus on a cost/benefit ratio when considering these changes.

An excellent trade off
I’m happy about categories getting all busted up to hell because they desperately need to be refactored in order for TXP to grow.

Sometimes I need to create duplicate categories for all content types
Being limited to 2 categories per article is a huge roadblock in building sophisticated sites.
Custom url schemes get totally fubared by categories with duplicate names

So I’ll gladly recode sites/plugins to get better category handling. I’ll “pay the cost to be the boss” of categories without heistation.

A questionable trade off
In contrast, the idea of merging “forms” and “pages” into “templates” doesn’t seem to have a functional effect beyond some people’s semantic preference. Granted, I think “forms” is a confusing and misleading term given it’s ambiguity in relation to <form>. Calling it “snippets” would be far more accurate. But beyond that, where is the function? How does it make building sites easier? And to acheive this dubious improvement, the effect on plugins would be dramatic. On a personal level it would create a huge workload/expense for me to rebuild plugins and sites.

Thoughts?

maverick · 2011-03-02 17:51:43

mrdale wrote:

Just want to weigh in on “pages” & “forms” being merged into “templates”.

mrdale – can you refresh me as to where in the thread this is proposed? I’ve been following it since it began, and can’t remember that idea, or find it . . . I’m sure I’m just overlooking it :-) .

I think “forms” is a confusing and misleading term given it’s ambiguity in relation to <form>. Calling it “snippets” would be far more accurate.

Agreed that “forms” could be more accurately named. Snippets seem to be popular in the software world, and because it doesn’t have the “form” ambiguity, is an improvement. Though I think for the lay person it’s not a word they can automatically relate to either. Perhaps pieces, parts, chunks, ingredients, or some other like term would offer even greater clarity and easy conceptual transfer.

Last edited by maverick (2011-03-02 17:52:35)

merz1 · 2011-03-02 18:52:34

Perhaps pieces, parts, chunks, ingredients, or some other like term would offer even greater clarity and easy conceptual transfer.

Well, I refer to them as bricks like in ‘LEGO bricks’. But ‘form’ is totally OK for me.

I am fine with ‘pages’. My alternative would be ‘markup’ which also fits pretty well to the XTML style of TXP tags. ‘Template’ is so 90s aka web 1.0.

Manfre · 2011-03-02 19:39:12

mrdale wrote:
Just want to weigh in on “pages” & “forms” being merged into “templates”.

maverick wrote:
mrdale – can you refresh me as to where in the thread this is proposed? I’ve been following it since it began, and can’t remember that idea, or find it . . . I’m sure I’m just overlooking it :-) .

First post mentioning merging is post #13 where Ruud put it as a wishlist.

Last edited by Manfre (2011-03-02 19:41:12)

maverick · 2011-03-02 20:14:11

Manfre wrote:

First post mentioning merging is post #13 where Ruud put it as a wishlist.

Thanks!

michaelkpate · 2011-03-02 20:55:43

ruud wrote:

Wishlist:

Combine “forms” and “pages” into “templates”. There’s really no reason to separate the two (or differentiate between various types of forms) and calling it a “template” is less confusing.

artagesw wrote:

This is the approach Escher takes.

Actually, separate pages and “snippets” is the method I always prefer. For instance, from one of my Movable Type Index Templates:

<div id="content"><div class="col-one">			
<$MTInclude module="2008-entry content"$>
</div></div>

and what does 2008-entry content Included Module consist of?

<div id="entry-<$MTEntryID$>">
<h2><$MTEntryTitle$></h2>
<p class="entryinfo">
Posted by <$MTEntryAuthorLink show_hcard="1"$>
</p>
<$MTEntryBody$>
<p class="entrymeta">
<span class="date"><$MTEntryDate format="%x"$></span>	
</p>
</div>

I like keeping the page templates as brief as possible so I can see at a glance what the page is doing. Even the new WordPress templates like TwentyTen have simplified the code down:

		<div id="container">
			<div id="content" role="main">
			<?php
			/* Run the loop to output the posts.
			 * If you want to overload this in a child theme then include a file
			 * called loop-index.php and that will be used instead.
			 */
			 get_template_part( 'loop', 'index' );
			?>
			</div><!-- #content -->
		</div><!-- #container -->

I probably need to go read more, but I would be very sad if that feature goes away.

Last edited by michaelkpate (2011-03-02 21:05:28)

maverick · 2011-03-02 21:44:13

ruud wrote:

Wishlist:

Combine “forms” and “pages” into “templates”. There’s really no reason to separate the two (or differentiate between various types of forms) and calling it a “template” is less confusing.

maniqui wrote:

I like ruud’s suggestion on “merging” both Pages and Forms under the same tab … although I would keep some kind of categorization.

Combining “forms” and “pages” without keeping some categorization could break this section-to-page-template paradigm, and users could make the mistake of trying to do section-to-any-chunk-of-txp-code, which, in current TXP4 paradigm won’t work (unless the “form” contains the full code for a template).

So is the idea proposed primarily a “UI concept” – e.g. to unify the form tab and the page tab into a generic “templates” tab? Then any “template” would be able to call another template (like a page is able to call a form)?

Or is it a more fundamental shift away from having chunks of reusable code?

I guess I’m not sure what Ruud means. I’m being a bit dense I suppose ;)

artagesw wrote:

This is the approach Escher takes.

Now that I went back and read this, I realize I’m not entirely sure what Sam means since Escher has Themes, Templates, and Snippets. Perhaps I’m mistaken, but Templates and Snippets in Escher seems to be the equivalent of Page Templates and Forms in Txp. . . .???

ruud · 2011-03-02 22:40:23

My wish to combine “forms” and “pages” into “templates” is mainly because:

technically and functionally there is little or no difference between the two, so why carry around extra code to support something that can be simplified without losing functionality.
forms and pages are really nothing but a hard-coded categorization of templates. Combine it on one tab and allow user-defined categorization (unlike the pre-defined form types). One way to do user-defined categorization of templates is to allow templates to have parents and children, so you can organize them in a tree structure (similar to how it works on the category tab).
I really can’t express how much I dislike the words “forms” and “pages” in this context. Very confusing. I’d prefer “templates”, which does not confuse.

mrdale · 2011-03-02 23:05:23

ruud wrote:

My wish to combine “forms” and “pages” into “templates” is mainly because:

technically and functionally there is little or no difference between the two, so why carry around extra code to support something that can be simplified without losing functionality.

Conceptually and organizationally I consider these to fill completely different functions. Page is always top level. And it provides a clear heirarchy for new users. “On this section I use this page”. use forms extensively and don’t want to trade my two tabs for one tab with more items. top level forms (templates) will simply disappear in the cluter.

You could make the argument that “styles” are just “forms” too, now that we’re done with all that base-64 nonsense.

forms and pages are really nothing but a hard-coded categorization of templates. Combine it on one tab and allow user-defined categorization (unlike the pre-defined form types). One way to do user-defined categorization of templates is to allow templates to have parents and children, so you can organize them in a tree structure (similar to how it works on the category tab).

This is a fine organizational device, but the reality of it is, I often use one form to serve many, many areas of my site on multiple pages, so I’m not sure of the benefit of the herarchial categorization you envision. Please explain.

I really can’t express how much I dislike the words “forms” and “pages” in this context. Very confusing. I’d prefer “templates”, which does not confuse.

Pages is not confusing, forms are a misnomer, I agree. Frankly I don’t care if I have to search and replace all instances <txp:output_form form="foo" /> with <txp:snippet name="foo"/>

Textpattern CMS

Textpattern CMS support forum

#91 2011-02-18 15:14:19

Re: The direction of Textpattern 5

#92 2011-02-18 15:26:21

Re: The direction of Textpattern 5

#93 2011-02-18 15:50:33

Re: The direction of Textpattern 5

#94 2011-02-18 16:12:06

Re: The direction of Textpattern 5

#95 2011-02-18 16:21:45

Re: The direction of Textpattern 5

#96 2011-02-18 19:39:41

Re: The direction of Textpattern 5

#97 2011-03-02 17:27:47

Re: The direction of Textpattern 5

#98 2011-03-02 17:51:43

Re: The direction of Textpattern 5

#99 2011-03-02 18:52:34

Re: The direction of Textpattern 5

#100 2011-03-02 19:39:12

Re: The direction of Textpattern 5

#101 2011-03-02 20:14:11

Re: The direction of Textpattern 5

#102 2011-03-02 20:55:43

Re: The direction of Textpattern 5

#103 2011-03-02 21:44:13

Re: The direction of Textpattern 5

#104 2011-03-02 22:40:23

Re: The direction of Textpattern 5

#105 2011-03-02 23:05:23

Re: The direction of Textpattern 5

Board footer