On 1/30/07, Jacob B. [email protected] wrote:
Ahh, attempting to implement 2 features at once? re-ordering as well as
parent/hierarchy changing?
(snipped a bunch)
#199 actually has a patch that does re-ordering quite well (some
assembly required, but I’m using it on a few sites). As it stands,
the icon/grabber is not pretty. I was thinking it could be tweaked by
putting the grabber on the end (or beginning) of the row as a textured
rectangle.
The re-parenting portion of it is no-good though, as it uses rather
unattractive arrow icons that clutter up the UI a bit. I use the patch
without re-parenting because I personally think re-parenting is bad
(breaks URL’s… if you are careful with your site you shouldn’t really
need to do it… in a perfect world).
-Tom
John W. Long wrote:
Loren J. wrote:
I don’t currently feel qualified to work-up a new patch nor improve
the existing one, but I’ve got $$$ (seriously) for the first one to
do it well enough to get it included in a core release.
I have a client who wants to help foot the bill for this. Contact me
directly if you want to help.
Here’s the first pass after a day’s work (works with mental):
http://dev.radiantcms.org/radiant/attachment/ticket/45/sortable_pages.mental.diff
The patch doesn’t address the reparenting issue. I’m going to have a go
at that as well, but am working on this this in iterations.
Please have a look if you have a moment.
–
John L.
http://wiseheartdesign.com
Here’s the first pass after a day’s work (works with mental):
http://dev.radiantcms.org/radiant/attachment/ticket/45/sortabl
e_pages.mental.diff
The patch doesn’t address the reparenting issue. I’m going to
have a go
at that as well, but am working on this this in iterations.
What happened to the original work of changing the page list to be
's and - 's and just directly allowing sorting there? I remember
things moving enthusiastically in that direction but then falling off
the radar. Were there issues with making it render properly
cross-browser?
I was planning on doing some work to allow pages to break their children
up into independently expanding sections (ie, by year on the archive
pages so you don’t get 1200 articles loading up), but was planning on
switching to a list-based view first.
Dan.
John,
This looks good to me. I may have preferred to not going to a
separate screen but don’t really have any objection to it either –
this works for me.
I’m very happy to see the default sort order priority beginning with
position.
Thanks for putting this out there, it’s great to see this coming
together, or at least beginning 
Great!
Loren
Daniel S. wrote:
What happened to the original work of changing the page list to be
's and - 's and just directly allowing sorting there? I remember
things moving enthusiastically in that direction but then falling off
the radar. Were there issues with making it render properly
cross-browser?
I know there is a lot of built in support for sorting lists in Rails,
but I’m still hoping a solution can be pulled together that’s not too
complicated and uses a tables.
I’ve looked at some of the other sorting patches, but they seem to be
incompatible with mental.
–
John L.
http://wiseheartdesign.com
I know there is a lot of built in support for sorting lists in Rails,
but I’m still hoping a solution can be pulled together that’s not too
complicated and uses a tables.
I’ve looked at some of the other sorting patches, but they seem to be
incompatible with mental.
Well, the changing of the code from tables to lists made for much
cleaner html, ruby and javascript code (at the expense of more
complicated css). I think it would be a good idea to go ahead with that
regardless of sorting - predicated of course on having css that works
cross-browser.
I created a sorting patch in my ‘on crack’ branch - I might dig that
back up in the near future and see how that goes.
Also the discussion on reparenting - I don’t think reparenting should be
a drag/drop operation - I quite liked to idea of having a ‘parent’
drop-down list in the page metadata (though that also has the problem
with large numbers of pages). I’d also like to see the option of leaving
behind a redirect action to maintain cool uris.
Dan.
I assume user input is welcome here…
I have a “small” business site that will easily have 100-200 pages that
I’m planning to move to radiant. On its way to publication, it is
common to adjust the parent of a page as we settle on our structure and
linking.
I don’t think reparenting should be a drag/drop operation - I quite liked to
idea of having a ‘parent’ drop-down list in the page metadata (though that
also has the problem with large numbers of pages).
A drop-down list would be hard on the writers having to read through all
possible parents. By the way, I am more likely to move a page up or
down a level than to move it laterally (make its aunt/uncle its new
parent). A lot has to do with the interface design, but teaching users
one operation (drag-drop) for everything should be easier than
remembering two and when each is to be used.
Another thought. I’ve only looked briefly at things like scriptaculous
JS drag-drop operations. Do they allow for cases where the destination
location is off-screen (scrolling needed)? Otherwise you still run into
problems with large numbers of pages (though you could move a page using
multiple hops).
I’d also like to see the option of leaving behind a redirect action to
maintain cool uris.
BIG thumbs up for this idea. I wish all the uri adjusting only happened
on the way to publishing but the real world doesn’t seem to always work
that way for me.
I’d also like to see the option of leaving
behind a redirect action to maintain cool uris.
I think it should be easy enough to write a tag for doing redirects…
(You don’t need a special kind of “redirect” page, you can just create a
new page and insert this tag). Or perhaps this tag should actually be
provided by a custom page type…
Here’s some snippets of code from my own hacked-up version of Radiant:
—in standard_page.rb—
<r:redirect to_url="" />
define_tag ‘redirect’ do |tag|
to_url = tag.attr[‘to_url’]
raise RedirectException.redirect_to(to_url);
end
------redirect_exception.rb—
class RedirectException < Exception
attr_accessor :redirect_to_url
def self.redirect_to(redirect_to_url)
new_exception = RedirectException.new(“redirect”);
new_exception.redirect_to_url = redirect_to_url;
return new_exception;
end
end
----in site_controller.rb----
def show_page
url = params[:url].to_s
@page = find_page(url)
if @page.nil?
render :template => ‘site/not_found’, :status => 404
else
begin
@page.process(request, response)
rescue RedirectException => e
redirect_to e.redirect_to_url;
end
@performed_render = true
end
rescue Page::MissingRootPageError
redirect_to(:controller => ‘admin/welcome’)
end
Daniel S. wrote:
Also the discussion on reparenting - I don’t think reparenting should be
a drag/drop operation - I quite liked to idea of having a ‘parent’
drop-down list in the page metadata (though that also has the problem
with large numbers of pages).
I think I favor drag and drop reparenting, but with the option to
“Cancel” if you make a mistake. Much like the implementation of the
current reordering patch.
I’d also like to see the option of leaving
behind a redirect action to maintain cool uris.
Not sure about this myself. I have a feeling a lot of users would find
this very annoying.
–
John L.
http://wiseheartdesign.com
Here’s another suggestion for how you could potentially select a new
parent for a particular page.
From the edit screen you see a basic text box with the URL of the parent
page.
If you start typing into this box, it becomes an AJAX-y auto-complete
box with the names of pages whose page name or url matches what you are
typing…
when you select a parent, the full url is shown in the text box.
When you actually save the page you were editing, the controller has to
figure out the actual page object that corresponds to the url and assign
it as the parent, with validation etc…
Do we all think that re-ordering and re-parenting should be part of the
core of radiant, or an extension?
How, in general, do we ever decide this sort of thing?
If you start typing into this box, it becomes an AJAX-y auto-complete
box with the names of pages whose page name or url matches what you are
typing…
when you select a parent, the full url is shown in the text box.
The issue with separating parenting from ordering is twofold:
1.) Two different actions for the user to learn.
2.) If you want the 2nd document under parent #1 to become the 3rd
document under parent #2, you have to do two steps. Parent, then order.
Fundamentally, it just goes against the user’s goal. In the their mind,
the thought is simply “I want this moved to here” and a single operation
follows that thinking.
The complexity of implementation – well that’s a whole other issue.
BTW, John W. Long wrote:
I think I favor drag and drop reparenting, but with the option to
“Cancel” if you make a mistake. Much like the implementation of the
current reordering patch.
The cancellation step is where I would provide the option of
automatically creating a redirect page upon completion (say, a box –
unchecked by default – to preserve the old uri).
If you want to get really fancy, you could control the default checkbox
state or even if the user has that option in some admin configuration.
This way an admin could establish it as a site policy.
I think it should be easy enough to write a tag for doing
redirects…
(You don’t need a special kind of “redirect” page, you can
just create a
new page and insert this tag). Or perhaps this tag should
actually be
provided by a custom page type…
Since the changes that we’re talking about are on mental, it’s actually
MUCH simpler to just introduce a redirect page than to bastardize the
tags.
class RedirectPage < Page
def headers
location = part(‘content’).content
{
‘Status’ => 302,
‘Location’ => location
}
end
def render
‘’
end
end
You’d probably also want a page status that takes the page out of the
‘<r:children>’ set, yet still makes the page available for rendering
(the hidden status doesn’t cover that does it?)
Dan.
Daniel S. wrote:
MUCH simpler to just introduce a redirect page than to bastardize the
def render
‘’
end
end
You’d probably also want a page status that takes the page out of the
‘<r:children>’ set, yet still makes the page available for rendering
(the hidden status doesn’t cover that does it?)
You could make the page “virtual”.
def virtual?
true
end
–
John L.
http://wiseheartdesign.com
Jacob B. wrote:
Do we all think that re-ordering and re-parenting should be part of the
core of radiant, or an extension?
How, in general, do we ever decide this sort of thing?
Generally, I just make a decision and people live with it. 
Specifically, I try and listen to other opinions and implement the ideas
I like best.
–
John L.
http://wiseheartdesign.com
On 1/30/07, John W. Long [email protected] wrote:
http://dev.radiantcms.org/radiant/attachment/ticket/45/sortable_pages.mental.diff
The patch doesn’t address the reparenting issue. I’m going to have a go
at that as well, but am working on this this in iterations.
Please have a look if you have a moment.
It works well, though IMO it is more intuitive to allow DnD
re-ordering in the main Pages view.
-T