Perhaps I should have changed the subject line, but the comment scheme
I’m
describing has nothing to do with page parts, but rather subpages.
Thanks for explaining your perspective, John.
On 7/23/06, John W. Long [email protected] wrote:
My goal with Radiant is to make it easier for small teams to manage
information centric Web sites: brochure sites, blogs, portfolios, etc…
Radiant’s a tool for people who are frustrated with existing blogging
solutions because they are too blogging centric. In a nutshell it’s for
building a site that is just a little bigger than a blog. If you are
trying to do something outside those bounds you may need to look for or
build a different tool.
OK, given that I see that you have a different idea of “just a little
bigger
than a blog” than I do.
So it sounds like Radiant (or at least its core) shalt not grow a
feature
set much beyond what it has now. To try out ideas like I’ve described,
can I
get commit access on a branch, or do I fork? Not sure when I’ll be able
to
do so, but something with the flexibility I’m envisioning could be
useful at
work.
Ryan P. wrote:
Is there a specific reason why you believe this isn’t a good path, or are
you just hesitating (not a bad idea when considering a feature)?
I think this sums it up well:
“Blurring the line between page parts and comments might make it
easier for developers to create solutions to other problems, but I
fear that it would make it more difficult for the average user who
just wants to add comments to their blog.”
And yes, I am hesitating. I don’t think it’s a good idea, but I am open
to being shown a better way (if I’ve seen it I haven’t recognized it as
such, yet).
You and other Radiant users already need some way to support commenting,
don’t you? I’m pointing out a way to implement commenting in Radiant that
will slightly generalize the tool for broader purposes rather than creating
a new narrow feature that builds in more assumptions.
I think I favor the clean conceptual break, rather than blurring the
line with page parts or sub-pages as you suggest.
My goal with Radiant is to make it easier for small teams to manage
information centric Web sites: brochure sites, blogs, portfolios, etc…
Radiant’s a tool for people who are frustrated with existing blogging
solutions because they are too blogging centric. In a nutshell it’s for
building a site that is just a little bigger than a blog. If you are
trying to do something outside those bounds you may need to look for or
build a different tool.
This is what I mean when I say that Radiant has limited scope.
–
John L.
http://wiseheartdesign.com
If the radiant engine patch ever makes it into the trunk you can just
build an engine for it with your own views…
Josh F.
John W. Long wrote:
Ryan P. wrote:
So it sounds like Radiant (or at least its core) shalt not grow a feature
set much beyond what it has now. To try out ideas like I’ve described,
can I get commit access on a branch, or do I fork?Would something like SVK (http://svk.elixus.org/) work for this? I’d be
fine with giving you a branch, but perhaps it would be better for you to
build some momentum first?
+1 for SVK. Mirror the Radiant SVN trunk, and plug away at your local
branch. svk pull periodically to merge in changes from the remote.
Works like a charm, and preserves all the SVN semantics.
-P
Ryan P. wrote:
Thanks for explaining your perspective, John.
Sure. 
Thanks for pushing for an explanation.
OK, given that I see that you have a different idea of “just a little
bigger than a blog” than I do.So it sounds like Radiant (or at least its core) shalt not grow a feature
set much beyond what it has now. To try out ideas like I’ve described,
can I get commit access on a branch, or do I fork?
Would something like SVK (http://svk.elixus.org/) work for this? I’d be
fine with giving you a branch, but perhaps it would be better for you to
build some momentum first?
Not sure when I’ll be able to do so, but something with the
flexibility I’m envisioning could be useful at work.
What feature set do you need for work?
–
John L.
http://wiseheartdesign.com
On 23/07/2006, at 11:23 AM, dror tirosh wrote:
sorry missed the link before the files are in:
http://www.drortirosh.com/source
Dror, I hope you don’t mind, I created a patch for your work and added
a ticket to Trac [1]. From the quick look I had while preparing the
patch, I noticed a couple of things:
- tests would be nice
- there will be problems when files of the same name are attached
- i changed the content method for the attachment type to return the
url to the file, I imagine this will cause problems if radiant is used
in a subdirectory (can radiant be used in a subdirectory anyway?)
I posted the patch so others can try it out more easily. Thanks a lot
for starting this and sharing your code with us! I’m going to need this
in my current project at work.
Bodhi
bodhi wrote:
Dror, I hope you don’t mind, I created a patch for your work and added
a ticket to Trac [1]. From the quick look I had while preparing the
patch, I noticed a couple of things:
- tests would be nice
- there will be problems when files of the same name are attached
- i changed the content method for the attachment type to return the
url to the file, I imagine this will cause problems if radiant is used
in a subdirectory (can radiant be used in a subdirectory anyway?)I posted the patch so others can try it out more easily. Thanks a lot
for starting this and sharing your code with us! I’m going to need this
in my current project at work.Bodhi
I ask myself if this should be a new topic since I am not writing about
comments and the Radiant philosophy, but rather about attachments. I
will go with the flow for now.
Ok, thanks to Bodhi and Dror I actually got this going. This looks a
real winner to me. With a few small modifications, I got the images to
display in the Radiant interface (and went ahead and made an “image”
attachment type, in case I want to upload something and not display it).
I also added a radius tag for r:image with a class and alt attribute,
all very rough but working. This fills a very big hole for me
personally. It is still all a bit rough around the edges (error handling
in particular is still not well implimented) but does show a nice way
forward for attachments.
I am wondering how to add some RMagick stuff and various attachement
types, but that will have to wait.
Keith
Paul S. wrote:
+1 for SVK. Mirror the Radiant SVN trunk, and plug away at your local
branch.svk pullperiodically to merge in changes from the remote.
Works like a charm, and preserves all the SVN semantics.
That could actually be a great solution for the “I want Radiant to do
everything” vs. “let’s keep the core simple” issue overall - various
Radiant branches with expanded featuresets, and people can pull
whichever branches they want together. Much better than forking, and it
keeps the core simple.
Jay
Keith B. wrote:
I just noticed a bug in this: when deleting a page part, while it give a
confrimation, deletes the attached file/image/whatever, the page part is
still there when the page is reloaded. This is true of any page part,
not just attachments. I will try to see what is going on, but my skills
are in, shall we say “development”.
I have been noticing that with 1.5 release, but not often enough to nail
down a fail case. It may not be new bug.
JAy
Jay L. wrote:
Keith B. wrote:
I just noticed a bug in this: when deleting a page part, while it give a
confrimation, deletes the attached file/image/whatever, the page part is
still there when the page is reloaded. This is true of any page part,
not just attachments. I will try to see what is going on, but my skills
are in, shall we say “development”.I have been noticing that with 1.5 release, but not often enough to nail
down a fail case. It may not be new bug.JAy
With the 1.5 release, I have not had any problems. But when this patch
is applied, it seems completely broken. The attachments get deleted, but
the part itself does not.
Keith B. wrote:
bodhi wrote:
Dror, I hope you don’t mind, I created a patch for your work and added
a ticket to Trac [1]. From the quick look I had while preparing the
patch, I noticed a couple of things:
- tests would be nice
- there will be problems when files of the same name are attached
- i changed the content method for the attachment type to return the
url to the file, I imagine this will cause problems if radiant is used
in a subdirectory (can radiant be used in a subdirectory anyway?)I posted the patch so others can try it out more easily. Thanks a lot
for starting this and sharing your code with us! I’m going to need this
in my current project at work.Bodhi
I ask myself if this should be a new topic since I am not writing about
comments and the Radiant philosophy, but rather about attachments. I
will go with the flow for now.Ok, thanks to Bodhi and Dror I actually got this going. This looks a
real winner to me. With a few small modifications, I got the images to
display in the Radiant interface (and went ahead and made an “image”
attachment type, in case I want to upload something and not display it).
I also added a radius tag for r:image with a class and alt attribute,
all very rough but working. This fills a very big hole for me
personally. It is still all a bit rough around the edges (error handling
in particular is still not well implimented) but does show a nice way
forward for attachments.I am wondering how to add some RMagick stuff and various attachement
types, but that will have to wait.Keith
I just noticed a bug in this: when deleting a page part, while it give a
confrimation, deletes the attached file/image/whatever, the page part is
still there when the page is reloaded. This is true of any page part,
not just attachments. I will try to see what is going on, but my skills
are in, shall we say “development”.
Hey guys,
Thanks Bodhi for making the patch.
I created the page part types functionality since I thought page parts
of
different types can solve a lot of the issues that arised on the mailing
list. I tested the page parts functionality (mainky the SimplePagePart
class) using radiant tests, since in reality this only reimplements the
same
as the old functionality, but at the same time allows for adding more
functionality.
One very important thing, I created the event, attachment and other page
parts as a proof of concept for the use of the new functionality, and I
think they are far from perfect. They are there just to give people
ideas
with things that appeared on the mailing list.
A few years back I used the Drupal CMS, and took part in developing a
few
models and patches to that system. I think Drupal has a very big number
of
Modules and functionality (I have to admit the core has grown way too
big
for my liking) mainly based on a system of simple hooks. What I did was
just
to implement a hook into the Radiant core. I think with the simplicity
of
the Radiant core at the moment and the beuty of Ruby and Rails, we can
create a few more hooks that will allow developers to enhance Radiant
while
keeping the core functionality simple.
I think that the way Radiant is constructed already allows many things
that
other CMSs do not allow, and I think the number of necesary hooks is
minimal, but I think is worth looking into now, before the core becomes
too
complex to add thoe hooks.
John, if you think this is a good idea, I’ll suggest starting a new
thread
talking about places to add these hooks.
I also talked before in this thread about moving behaviors to the page
part
level (from the page level), I think this will allow adding a lot of
functionality to websites based on Radiant. Whatdo you think?
Dror
dror tirosh wrote:
I also talked before in this thread about moving behaviors to the page
part level (from the page level), I think this will allow adding a lot
of functionality to websites based on Radiant. Whatdo you think?
+1
Hi Keith,
I just noticed I fucked something up, I’ll send an updated file soon.
Dror
On 7/24/06, Jay L. [email protected] wrote:
dror tirosh wrote:
I also talked before in this thread about moving behaviors to the page
part level (from the page level), I think this will allow adding a lot
of functionality to websites based on Radiant. Whatdo you think?
+1
Hi,
I attach two files, that fix a bug of page_parts not being erased, when
deleted.
I was trying to minimize the changes to the page_controller.rb file, but
I
ended up not testing it before sending the files, sorry.
Bodhi, I’ll appriciate it if you can fix the patch.
Dror
On 25/07/2006, at 6:03 AM, dror tirosh wrote:
Hi,
I attach two files, that fix a bug of page_parts not being erased,
when deleted.
I was trying to minimize the changes to the page_controller.rb file,
but I ended up not testing it before sending the files, sorry.
Bodhi, I’ll appriciate it if you can fix the patch.
Done. By the way Dror, theres a small typo in your
app/page_part_types/attachment_part_type.rb , the class name has two
letters transposed: “AttachemntPagePart”. Its fixed in the patch.
Once more and i think i might have to install svk
thanks
Dror, I hope you don’t mind, I created a patch for your work and added
a ticket to Trac [1].
Stupid question maybe but how exactly do you apply these patches to a
Radiant instance? Should I use the svn patch command on the diff
file? And does this work for the gem version, or only for the SVN
version?
–
Jeroen J.
Laika online entertainment