Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2016-10-18 13:47:55

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,778
Website

Re: RFC: 'Show details' column picker

etc wrote #302292:

IIRC we deliver the page hidden until all scripts have done their job

Aye, probably. Haven’t checked for a while.

IIRC we currently pass them WHERE clause that they can alter and return, right?

Yes.

We should probably give them a possibility to return also their array of retrieved data that will then be merged with core? Not clear atm…

Interesting. We could do that as long as we’re sure that the number of rows in their result set is the same! The advantage to just adding simple columns to the core query is that the WHERE clause guarantees that. But it’s more flexible to allow their own results to be merged in as that would permit custom joins. Runs the risk of something going wonky when rendered if the number of rows differ. Could we guard against that somehow?

If by “entire” you mean “not paginated”, that could be fat…

No, I mean as it is now — paginated — but with every column represented so they can be manipulated client side. Sorry if I wasn’t clear.


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

#12 2016-10-18 13:58:53

etc
Developer
Registered: 2010-11-11
Posts: 3,343
Website

Re: RFC: 'Show details' column picker

Bloke wrote #302293:

Interesting. We could do that as long as we’re sure that the number of rows in their result set is the same! The advantage to just adding simple columns to the core query is that the WHERE clause guarantees that. But it’s more flexible to allow their own results to be merged in as that would permit custom joins. Runs the risk of something going wonky when rendered if the number of rows differ. Could we guard against that somehow?

Very true, and I have no answer to this atm. Maybe altering SELECT is less risky…

No, I mean as it is now — paginated — but with every column represented so they can be manipulated client side. Sorry if I wasn’t clear.

That’s what I understood few seconds after replying, sorry :-) Yes, client side it’s just a table, whatever its source. The only problem is that locally stored column states will get out of sync if a column is deleted (with its plugin). I have no easy solution here, neither.

Offline

#13 2016-10-18 14:04:24

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,778
Website

Re: RFC: 'Show details' column picker

etc wrote #302294:

The only problem is that locally stored column states will get out of sync if a column is deleted (with its plugin).

Presumably if a column is missing when it comes time to hide them, as long as each column has some unique textual name (not simply a numeric offset) then any column not present in the actual table can be purged from local storage. Or have I misunderstood?


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

#14 2016-10-18 15:30:33

sacripant
Plugin Author
From: Rhône — France
Registered: 2008-06-01
Posts: 478
Website

Re: RFC: 'Show details' column picker

Just a UX suggestion :
Personnaly, I don’t want more Jquery script or Javascript loaded by default in write mode.

I propose to just add a “configuration” btn in each target tab. When click on this button, you load necessary script and toggle to a “personalisation mode” with drag & drop, delet block btns, add block / row btn etc with a save configuration btn.
With this solution you can create a specific user interface that is not charged by default when you load pages.

Offline

#15 2016-10-18 15:34:48

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,778
Website

Re: RFC: 'Show details' column picker

sacripant wrote #302298:

I don’t want more Jquery script or Javascript loaded by default in write mode.

Well this isn’t the Write panel we’re talking about here, but I take your point.

I like the idea of a config mode. That has the potential to be very useful. Especially since clicking on things and accidentally moving the mouse a few pixels triggers ‘drag mode’ which means your click action isn’t executed. Having a dedicated mode for moving stuff about alleviates this potential problem.

Will definitely consider this, thanks.


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

#16 2016-10-18 16:07:37

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,598

Re: RFC: 'Show details' column picker

Forgive me if I’m inadvertently being That Guy, but perhaps a before-and-after or A/B mockup might be helpful, especially for forum folks with English as a non-primary language.

Respectfully, and I’m perhaps oversimplifying it, but here’s the gist of this thread: “We’d like your feedback on a visual/presentational thing in the Textpattern admin-side. Here’s a bunch of words to explain what that is.”

A mockup would be super for me. I say this because I’ve been working in WordPress/MotoPress/Cherry Framework since 8am and it’s been a really interesting reminder of how important UI/UX is to CMS.

It’s also been a really, really hard day figuring out the convoluted routes that 3rd party theme authors take with their wares and the liberties taken with odd frameworks. I need a beer.

Offline

#17 2016-10-18 16:17:49

etc
Developer
Registered: 2010-11-11
Posts: 3,343
Website

Re: RFC: 'Show details' column picker

Bloke wrote #302295:

Presumably if a column is missing when it comes time to hide them, as long as each column has some unique textual name (not simply a numeric offset) then any column not present in the actual table can be purged from local storage. Or have I misunderstood?

Good idea. It means we need to switch from html nodes iteration (current method) to storage iteration in some bwc way, but it should be feasible.

BTW, what part of this should be delegated to themes? I mean, a theme might wish to output data in its own way, not necessary as a table. Maybe it’s time to discuss a better data (core) / presentation (theme) admin-side separation?

Offline

#18 2016-10-18 17:25:47

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,778
Website

Re: RFC: 'Show details' column picker

gaekwad wrote #302300:

A mockup would be super for me.

I can’t find Phil’s 4.6 framework on the Internet at the moment, hence no mockup at present.

Even if I could find it, there are about ten different ways this could be done so confining him to one might be a waste of his time. This is just a tentative “what if” exploration of possible intent. If the overriding reaction so far had been “what the hell are you smoking?” then we could just drop the notion.

As it stands, it seems like it might have legs. I’ll see if I can coerce Phil into a mockup or three, but since they won’t be functional in any way I’m not sure how valuable they’ll be besides using the winner as a template when it comes to generating the markup in core. But that in itself is a useful exercise as it’ll give us a chance to see what we’re letting ourselves in for.

As soon as we have something to demo we’ll post it here so discussion can continue among those who understandably struggle with my verbiage. I apologise if I’m being abstruse.

etc wrote #302302:

what part of this should be delegated to themes? I mean, a theme might wish to output data in its own way, not necessary as a table. Maybe it’s time to discuss a better data (core) / presentation (theme) admin-side separation?

Absolutely. I have no idea of where the separation lies exactly, but splitting the current mish-mash of data and display into something more MVC is something I’m keen to explore. A “table” View, for example, would be grand!


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

Board footer

Powered by FluxBB