Re: [Radiant] Question/Poll for Shards developers
why not implement a default_content_for() method that you use to display the
radiant admin's content and then provide methods to extension writters to
use the basic rails content_for() methods to override.
What's the rationale behind 'render_region' ?
Also, if possible give extension authors a choice.
In the radiant 'core' you might define part of the page edit screen with
default_content_for("edit_submit_buttons")
Then, give extension authors the option of either creating a
_edit_submit_buttons partial OR putting a content_for("edit_submit_buttons")
into a general "_edit_defaults" partial...
something like that...
With a bajillion little files, it's clear what I need to name my file and
where to put it in order to override a particular one of those files, If the
structure of these partials is going to change, it should be possible for an
extension to take the same structure and specifically override parts with
content_for like blocks...
just some ideas.
On 11/8/07, Sean Cribbs <[EMAIL PROTECTED]> wrote:
>
> Ryan,
>
> No, you shouldn't have to make any changes to your extensions.
>
> Sean
>
> Ryan Heneise wrote:
> > I like it - looks clean.
> >
> > Will we need to make any changes in current plugins that use Shards?
> >
> >
> >
> > On Nov 8, 2007, at 2:27 PM, Sean Cribbs wrote:
> >
> >
> >> Shards developers,
> >>
> >> I'm about to make a major change to the Shards extension's API and I
> >> want a little feedback from those who are using it. This is not a
> >> breaking change, per se, but a behavioral one. Let me set it up for
> >> you.
> >>
> >> Right now, the views (especially new/edit) for the
> >> Admin::PageController
> >> are broken into a bajillion little pieces so that we can have many
> >> points of insertion into the template. This is great for flexibility,
> >> but results in a bunch of tiny files and the need to dig through
> >> them to
> >> find the proper region when you want to insert something. I'd like to
> >> dramatically reduce the number of partials that ship with the
> >> extension.
> >>
> >> The solution to this, which I have working, is to move the partials
> >> back
> >> into one (or a few) files and provide a way to specify defaults, but
> >> still allow overriding of the partials in the file system. Here's an
> >> example of what I'm talking about. Normally, when you render a
> >> region,
> >> a line like this exists in the template:
> >>
> >> <%= render_region :my_region %>
> >>
> >>
> >> Via the 'admin' object, you would populate this region with partial
> >> names, which would be rendered from the file system in the order
> >> specified. If this region has default partials, as do the ones that
> >> come with Shards, they would instead be specified inline, where
> >> appropriate. Let's say "my_region" has default partials of "profile"
> >> and "sidebar"; this is how you would specify them (notice the
> >> removal of
> >> the =):
> >>
> >> <% render_region :my_region do |my| %>
> >> <% my.profile do %>
> >>...
> >> <% end %>
> >> <% my.sidebar do %>
> >>...
> >> <% end %>
> >> <% end %>
> >>
> >> This adds a bit of weight and noise to the templates, but
> >> significantly
> >> cuts down the number of partials. Regions that don't have any default
> >> partials could still be rendered in the manner shown in the first
> >> example (with the =). Let me know how you feel about this change.
> >>
> >> Sean
> >> ___
> >> Radiant mailing list
> >> Post: Radiant@lists.radiantcms.org
> >> Search: http://radiantcms.org/mailing-list/search/
> >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
> >>
> >>
> >
> > ___
> > Radiant mailing list
> > Post: Radiant@lists.radiantcms.org
> > Search: http://radiantcms.org/mailing-list/search/
> > Site: http://lists.radiantcms.org/mailman/listinfo/radiant
> >
> >
>
> ___
> Radiant mailing list
> Post: Radiant@lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Current status of facets branch
> * Model to cover adding features to the list pages, i.e. the main Pages, > Snippets and Layouts views, e.g. the existing ReOrder and CopyMove > extensions. > > * Model to cover adding features to the editor pages, i.e. editing > pages, snippets and layouts. Maybe let it select which internal > function to allow the enhancement to show on. This sounds good on a high level, but how do you go about actually implementing it? Is this a singleton model? one object covers the "page editing interface" and you manipulate that object to change that interface? Or, can you instantiate new page editing interfaces How does this "Model to cover adding features to the editor pages" provide hooks into extensions. If I were to create a "calendar" extension for instance, I would want it to be page type. And when you select calendar as a page type I should see a different page editing interface. And when you click save, there needs to be certain callbacks to my extension. How should all of this work... it's not clear. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Current status of facets branch
my reason for needing modularity: http://www.ruby-forum.com/topic/110943 On 8/20/07, Travis Bell <[EMAIL PROTECTED]> wrote: > > Hey guys, > > Please excuse my naivety here, but what are the benefits to having > "facets-like modularity"? > > Thanks, > > -- > Travis Bell > [EMAIL PROTECTED] > > > > > > On 20-Aug-07, at 8:33 AM, Jacob Burkhart wrote: > > > So maybe "procrastinating" isn't the best word > > > > I first released this: > > http://dev.eyebeam.org/projects/radiant-partatts/wiki > > > > then this: > > http://dev.radiantcms.org/radiant/ticket/508 > > > > There's even this, demonstrating why I think we need facets-like > > modularity: > > http://demo.kupenda.org/ and http://demo.kupenda.org/admin/ > > (login: demo, password: radiant) > > > > This is not a trivial problem. We're talking about significant > > change to > > the inner workings of radiant to add a complete layer of view > > abstraction. > > This isn't something that is going to be submitted as a single patch, > > approved and just work. > > > > We need to weight in on all the possibilities and explore the > > benefits and > > drawbacks to each. So that's why I say, make some plugins. > > > > > > > > On 8/19/07, John W. Long <[EMAIL PROTECTED]> wrote: > >> > >> Jacob Burkhart wrote: > >>> I too have tried to contribute to the expansion, improvement, and > >>> re-integration of facets... twice now > >> > >> Really? Did you announce your updates here on the mailing list? If we > >> miss something on trac, making a little noise about it here is > >> helpful. > >> > >> What ticket are we talking about? > >> > >> -- > >> John Long > >> http://wiseheartdesign.com > >> ___ > >> Radiant mailing list > >> Post: Radiant@lists.radiantcms.org > >> Search: http://radiantcms.org/mailing-list/search/ > >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant > >> > > ___ > > Radiant mailing list > > Post: Radiant@lists.radiantcms.org > > Search: http://radiantcms.org/mailing-list/search/ > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Silly question about running from a directory?
yes, not built for it. Start by playing with routes.rb On 8/19/07, Jim Gay <[EMAIL PROTECTED]> wrote: > > I recall some questions about this a few months ago and the answer > was that Radiant was not built for this. That's not to say that it's > not possible, but I don't know enough at the moment to help. > > You may get a better answer from someone else. > > On Aug 19, 2007, at 10:50 PM, Mohit Sindhwani wrote: > > > Sorry to bother you again, but is there any advice for me? > > > > Cheers, > > Mohit. > > 8/20/2007 | 10:50 AM. > > > > Mohit Sindhwani wrote: > >> Hi Everyone, > >> > >> Just a silly question. I was wondering if Radiant can be run from a > >> sub-directory (not a subdomain or as the main site of a domain). I > >> installed it to http://example.com/radiant and it starts up fine. > >> But, > >> when I log in to the admin area and click on the layouts tab, it > >> wants > >> to take me to http://example.com/admin/layouts rather than > >> http://example.com/radiant/admin/layouts > >> > >> If I type it as http://example.com/radiant/admin/layouts it takes > >> me to > >> the correct page. Am I missing something simple? > >> > >> Cheers, > >> Mohit. > >> 8/18/2007 | 4:36 PM. > >> > >> > >> ___ > >> Radiant mailing list > >> Post: Radiant@lists.radiantcms.org > >> Search: http://radiantcms.org/mailing-list/search/ > >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant > >> > >> > >> > > > > > > ___ > > Radiant mailing list > > Post: Radiant@lists.radiantcms.org > > Search: http://radiantcms.org/mailing-list/search/ > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Current status of facets branch
So maybe "procrastinating" isn't the best word I first released this: http://dev.eyebeam.org/projects/radiant-partatts/wiki then this: http://dev.radiantcms.org/radiant/ticket/508 There's even this, demonstrating why I think we need facets-like modularity: http://demo.kupenda.org/ and http://demo.kupenda.org/admin/ (login: demo, password: radiant) This is not a trivial problem. We're talking about significant change to the inner workings of radiant to add a complete layer of view abstraction. This isn't something that is going to be submitted as a single patch, approved and just work. We need to weight in on all the possibilities and explore the benefits and drawbacks to each. So that's why I say, make some plugins. On 8/19/07, John W. Long <[EMAIL PROTECTED]> wrote: > > Jacob Burkhart wrote: > > I too have tried to contribute to the expansion, improvement, and > > re-integration of facets... twice now > > Really? Did you announce your updates here on the mailing list? If we > miss something on trac, making a little noise about it here is helpful. > > What ticket are we talking about? > > -- > John Long > http://wiseheartdesign.com > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Current status of facets branch
I too have tried to contribute to the expansion, improvement, and re-integration of facets... twice now My take is, the Core team isn't ready to seriously review patches and find a solution. They're procrastinating on the problem. I think if I were to try a third time I would simply write a plugin that duplicates all of the code of the current admin interface and then adds the needed 'facets-like' modularity. It's really a hack and not the way it should be done long term, but the power of Ruby makes it possible. Once you write that 'base-facets' plugin and written a bunch of plugins on top of that.. My theory is that you can more easily test the market for your facets-requiring plug-ins. If mainstream users of radiant can benefit from your admin-interface-changing plugin they are more likely to go through the effort of installing it and using it and giving honest useful feedback if they can simply install a set of extensions on their existing radiant installation (as opposed to having to download an old branch) THEN finally the core team will Know what they actually want the 'facets-like' functionality of the core radiant to be and properly address it. Do you see what I'm getting at? No disrespect to the core team, I think they are doing a great job maintaining a solid stable product. But if you want to experiment, build a plugin so everybody can install it onto their existing radiant. Once it's really popular, then the core team will accept your patch to make it possible "The right way". And then I'll be able to port my extensions... : ) On 8/15/07, Sean Cribbs <[EMAIL PROTECTED]> wrote: > > Damien McKenna wrote: > > So the facets-lite wasn't for the pages view? I just found it by > > searching trac for "facets". > > > > > Facets-lite was only for the page _editing_ interface, not the main > sitemap view. > > What were the original goals of the project? How were you intending it > > would work? What do you now want to change on it? If you could explain > > this we might be able to help steer it in the right direction? > > > > > The original goals of the facets branch were to compartmentalize parts > of the page-editing interface so that they could be more easily and > unobtrusively modified. It operates on the principle that view > templates and partials define 'regions' that are filled with other > partials at render-time. You can define the contents of the regions via > the 'admin' object. The sample extension does a good job of showing how > to use the object. > > There are some quirks to the interface, however, and I'm not sure it's > in the right place of the API/application. > > Right now I don't have a clear answer on what I would want to change, > but my general feeling is that some things aren't quite right. I'd have > to spend some time re-reading the code to see what needs fixing. > > > I was thinking a simply way to add an action column to the Pages list > > would be an ample start to any grander plans, that would allow us to > > start making extensions behave nicely. > > > > > This is one area in which facets needed to expand. It also needed to > cover the layout and snippets interfaces as well. > > > I'd like to be able to have the ReOrder and CopyMove extensions on the > > same page, playing nicely. I can rework the extensions to suit, but > > it's tweaking the core I'm nervous about. > > > > > > If you could document what you'd like Facets to do we could try to work > > towards that goal? > > > > > > > Yes, but I prefer not creating more work for myself - when v0.6.5 or 0.7 > > rolls out with a replacement I'll have wasted time getting. > > > > > > Yes. As mentioned though if I'm going to help I'd like to at least be > > working in the same direction as the main project, so my efforts don't > > go to waste. > > > Unfortunately, facets has become kind of the > cold-fusion-Perl-6-Duke-Nukem-Forever of the Radiant project. I agree > that the functionality is sorely needed; extensions that step on each > other are a real problem. Unless it becomes stable and mature, it won't > be merged into any other branches or trunk before 0.6.5 or 0.7. > > However, if you would like to contribute, I'd say first familiarize > yourself with the codebase and especially the tests. Then, checkout > facets and create a diff between it and trunk, then merge the changes > into your facets checkout. Once you have that, go after the most > accessible part of the code that you'd like to change. Write tests, > verify your changes. Submit a patch to the Trac. Since it's an > experimental branch, if your patch looks good, I'll be sure to accept > and apply it (once I find a minute... typing this email took a while > too!). > > > Sean > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > _
Re: [Radiant] Page Tree - Admin Area
The expanding tree javascript saves it's state to a cookie. So you might try deleting this cookie if you've upgraded and it's still not working. On 8/19/07, Mark Fischer <[EMAIL PROTECTED]> wrote: > > The online demo works perfectly. So is it an issue with Trunk? I > did install all of the patches as described in the prior emails. Too > strange. > -Mark > > > On Aug 19, 2007, at 7:02 AM, John W. Long wrote: > > >> Mark Fischer wrote: > >>> Is there ANY way to easily keep the tree open to the area I saved > >>> from last? So I don't have to open up the entire family tree each > >>> time I want to enter a new child, grand child, or great, great, > >>> great > >>> grandchild? Any help would be greatly appreciated. > >> Mmm. The tree should remain open. What version are you using? Do > >> you get > >> the same result on the demo site (http://demo.radiantcms.org)? > > > > Again, do you get the same result on the demo site? > > > > -- > > John Long > > http://wiseheartdesign.com > > ___ > > Radiant mailing list > > Post: Radiant@lists.radiantcms.org > > Search: http://radiantcms.org/mailing-list/search/ > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] More Page Editor Modularization
Hi, I've done some more work on the core of radiant in the direction of making it easier for extensions to override exactly the part of functionality in the site map or page editor as desired (without having to duplicate a ton of code) I was going to submit it a diff onto my open ticket in Trac, but the site appears to be down at the momment. So you can view the diff here: http://uploads.kupenda.org/radiant/modularization_more.diff and you can download an example extension that demonstrates how to use the new modularization here: http://uploads.kupenda.org/radiant/modularization_example.zip Please, let me know what you think. I'd really like to get these changes incorporated into the core of radiant so that I can port my page attributes extension properly You might try stoping by IRC for a chat about it... thanks, Jacob ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Re-Introducing: Page Attributes, Templates, ContentFromTemplate
Greetings,
I am please to announced that I recenly came into possession of some
extra free time. And would like to tell you all about what I've been
up to with Radiant.
The Short Story:
demo: http://demo.kupenda.org/admin (user/pw = demo/radiant)
svn: http://208.78.96.155/svn/radiant_kupenda/trunk/radiant/
I need your help to make this into an extension!
http://dev.radiantcms.org/radiant/ticket/508
The Long Story:
I recently left my job as a software engineer at a "Professional
Services" organization. One of the main things we did there was
customize and deploy an in-house Java CMS for our clients. It wasn't
very good, but the one thing it did have going for it were Content
Item types. For example: If you had a Jobs section on you website,
you would be able to create new Job-typed content. Instead of getting
just a title and single WYSIWYG content area, you would also get some
relevant fields to fill out like "date posted", "manager's name"
etc... Or maybe you would even be able to upload a PDF and attach it
to this Job Posting. The important thing was that the screen you saw
for creating a job looked different than the one you used for a
creating a normal page, it was customized specifically for Job
editing/creation.
The problem with creating this customization, was that it required the
developers to manually edit XML configuration files, create additional
database tables, write Servlets and Table-wrapping classes, etc,
etc... i.e. it wasn't easy enough.
So I saw radiant and thought: Structuring a piece of content in Page
Parts is sorta-like structuring your own content item type for each
page. Although, you can only structure html content, you can't
structure things like uploads, links, dates, strings, etc...
So I create Page Attributes. I added a tab to the Page editing
interface, and made it possible to create new attributes on a
particular page. (And then you can of course reference these
attributes with appropriate tags)
So this gave me the flexibility to create well-structured content, but
it exposed too much of that structure and gave too much power to
Content Editors who shouldn't be allowed to change the structure.
The solution to this problem, was to create a second Tab in the admin
JUST for content. Content Authors wouldn't be able to add or remove
parts or attributes they would just be able to change the values of
existing ones. And they wouldn't be able to add or delete pages
either. Also, Content authors could only change the contents of page
parts that were specifically marked as editable by them ("[X]
template").
Of course, this is too far, Content authors SHOULD be able to create
content, they just need some restrictions. They should only be able to
create content of specific pre-defined types. (like the Jobs-typed
content item)
Thus, 2 new pages types:
TemplatePage -- a page that can be used for the basis of creating new pages
ContentFromTemplatePage -- a page created by a Content Author
based on a TemplatePage, pre-populated with all the needed parts and
attributes.
To further facilitate this process I gave all pages an attribute of
"inherits from page". When a new ContentFromTemplatePage is created
it's set to "inherit from" the Template it was created from. This
allows layout-oriented non-editable page parts to remain in the
TemplatePage, and when edited to affect all relevant
ContentFromTemplatePages.
So now the Content Admin was setup so that you can create new pages
anywhere there's a TemplatePage to create on from. And you can delete
pages only if they are ContentFromTemplate pages.
This sort of setup allows the technical developer and the
non-technical content author to find a balance between who has control
over what. If a content author wants to edit or change something that
is beyond their control, the developer can enable or create a page
part just for that particular piece of content. It's all about
finding a balance for this user in terms of giving them just enough
control to do what they want to do, without adding anything extra that
would confused or frustrate them.
So anyway, I've released a public demo of what I'm describing (see
above), which is basically a dump from the live site www.kupenda.org
in which I as the developer am actively working with the content
author (Kupenda's founder) to provide the best possible
most-customized content editing interface.
Absolutely no ruby code was written to customize this structure
specifically for Kupenda. It's all possible through the admin with
attributes, page types, and the additional tags.
So now I need your help, and your voice, to make the Core Radiant
extensions system capable to handling the modifications I've made. I
don't think they had what I'm doing here in mind when they created the
extensions system. Please take a look at what I'm trying to
accomplish in: http://dev.radiantcms.org/radiant/ticket/508
This is only going to become a real extension if peop
[Radiant] Core Dev: Page Controller and Page Editor refactorings (part 2)
Hi,
So I've submitted another partial-patch to show how we might change
the page editor to support modularization.
Think of it as a completely different approach to accomplishing the
functionality of facets.
The idea is to take all of that usefull html in admin/page/edit.rhtml
and move into individual files under /admin/page/editor/...
As an example, I've created _title_fields.rhtml and changed edit.rhtml
to call "<%= editor_title_fields %>" to display it.
Now, this seems pretty simple right? and you may expect an
editor_title_fields to be declared in PageHelper.
Not so.. I'd like to be more generic than that. Instead PageHelper
defines method_missing and whenever you call a method that starts with
editor_ it will find the appropriate partial in admin/page/editors
What this means, is that if I want to extend or alter the page editor
title fields, all I need to do is write a helper that defines
editor_title_fields and include that helper in page_controller.
Since method_missing will only be called if the method is not found,
including a helper that explicitly defines editor_title_fields will
free the extension author from dealing with things like
alias_method_chain
You can of course call the original editor_title_fields in your override with
render_editor_partial('title_fields')
The idea is to replace most of the html in admin/page/edit.rhtml with
calls to partials in this manner. Then, if my extension makes a
really radical change to the page editor, I can provide my own
edit.rhtml and include the page helper to add in the stuff from the
existing page editor that I still need.
A further extension of this idea, would be to allow extensions that
create new page types, to define a single helper that provides the
needed modifications to edit.rhml to support this page type, and the
includsion of this helper would be done automatically for pages of
that type.
What do you think?
http://dev.radiantcms.org/radiant/attachment/ticket/508/page_editor_modularization.diff
Jacob
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Core Dev: Page Controller and Page Editor refactorings
> change the routes file to look something like this: > > map.with_options :path_prefix => "admin/" do |admin| > admin.resources :pages, :snippets, :layouts, :users, :extensions > end I tried this for the extensions controller, seems it should be simple enough right? commented out the extensions routes and added: map.with_options :path_prefix => "admin/" do |admin| admin.resources :extensions end and I get: undefined local variable or method `extension_index_url' for #<#:0x222df14> It seems in order to be able use named routes, we have to name each route explicitly: It seems that the line: extension.extension_index 'admin/extensions', :action => 'index' is what makes "extension_index_url" come to life and extension.extension_indexwithanothername 'admin/extensions', :action => 'index' would make "extension_indexwithanothername_url" come to life. Thoughts on how to get around this? ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Core Dev: Page Controller and Page Editor refactorings
The equivalent of what you've written is currently performed by abstract_model_controller in handle_new_or_edit_post as: model.attributes = params[model_symbol] which for the case of page is essentially: @page.attributes = params[:page] The problem with hooking in to this behavior is that in order to save the page parts we need to look at: params[:parts] Supporting your suggestion would require much more broad sweeping changes. On 6/4/07, Sean Cribbs <[EMAIL PROTECTED]> wrote: > Jacob, > > Looks like a good step in the right direction. I like your use of > association extensions. However, wouldn't it just be easier to do: > > Page.new(params[:page]) > > or > > @page.update_attributes(params[:page]) > > and not have to call update_associations? > > Generally the strategy if you take this route is to make an > attr(_writer/_accessor) with the desired name, then an after_save > callback that saves the associated models. > > Sean > > Jacob Burkhart wrote: > > Hi, > > > > I've started to do some refactoring/improvment of the strucutre of > > page, page_controller, and page_parts. And I plan on continuing in a > > similar vein with admin/page/edit.rhtml > > > > The goal of this particular iteration, is to make it possible for Page > > subclasses or extensions of the Page class to add has_many, > > belongs_to, or has_one etc.. relations to Page and NOT have to modify > > page_controller. Since PageParts is a has_many of Page, I have moved > > all of the logic related to the saving of page parts into an > > association extension. Page is setup to discover all association > > extensions that respond to :update_association and pass parameters to > > and save these association appropriately. > > > > http://dev.radiantcms.org/radiant/attachment/ticket/508/page_controller_refactor.diff > > Please give me feedback on the direction I'm going! > > > > thanks, > > Jacob > > ___ > > Radiant mailing list > > Post: Radiant@lists.radiantcms.org > > Search: http://radiantcms.org/mailing-list/search/ > > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > > > > > > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Core Dev: Page Controller and Page Editor refactorings
Hi, I've started to do some refactoring/improvment of the strucutre of page, page_controller, and page_parts. And I plan on continuing in a similar vein with admin/page/edit.rhtml The goal of this particular iteration, is to make it possible for Page subclasses or extensions of the Page class to add has_many, belongs_to, or has_one etc.. relations to Page and NOT have to modify page_controller. Since PageParts is a has_many of Page, I have moved all of the logic related to the saving of page parts into an association extension. Page is setup to discover all association extensions that respond to :update_association and pass parameters to and save these association appropriately. http://dev.radiantcms.org/radiant/attachment/ticket/508/page_controller_refactor.diff Please give me feedback on the direction I'm going! thanks, Jacob ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Core Dev: Page Controller
Thanks Sean.
Looks like posting on the mailing list gets a much faster reply that
posting on Trac.
So then a follow-up question would be, what's wrong with these
patches, why havn't they been replied-to?
http://dev.radiantcms.org/radiant/ticket/504
http://dev.radiantcms.org/radiant/ticket/502
Jacob
On 6/1/07, Sean Cribbs <[EMAIL PROTECTED]> wrote:
> We would love a patch, of course! This will also help in a future
> refactoring toward REST which is on the horizon.
>
> Sean
>
> Jacob Burkhart wrote:
> > Hey,
> >
> > I just read this post:
> > http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers
> >
> > And it made me think immediately of the old handle_new_or_edit_post in
> > page_controller
> > http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/page_controller.rb?rev=57
> >
> >
> > But now I go and look at the latest version, and I see it's been
> > cleaned up a bit, and there a new AbstractModelController seperating
> > the logic a bit.
> >
> > http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/page_controller.rb
> > and
> > http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/abstract_model_controller.rb
> >
> >
> > But still... you have a lot of logic in the controllers. And a lot of
> > that logic, if moved to the model, would be a lot easier to override
> > and modify in extensions.
> >
> > For instance, I'd like to see all the part-creating/arranging logic
> > moved into the Page model.
> >
> > 96 parts_to_update = {}
> > 97 (params[:part]||{}).each {|k,v| parts_to_update[v[:name]] = v }
> > 98
> > 99 parts_to_remove = []
> > 100 @page.parts.each do |part|
> > 101 if(attrs = parts_to_update.delete(part.name))
> > 102 part.attributes = part.attributes.merge(attrs)
> > 103 else
> > 104 parts_to_remove << part
> > 105 end
> > 106 end
> > 107 parts_to_update.values.each do |attrs|
> > 108 @page.parts.build(attrs)
> > 109 end
> > 110 if result = @page.save
> > 111 new_parts = @page.parts - parts_to_remove
> > 112 new_parts.each { |part| part.save }
> > 113 @page.parts = new_parts
> > 114 end
> >
> > So, my question to the core devs is... how open would you be to patch
> > coming from me, that addresses some of these things.
> >
> > I must admit, my agenda is based on making my own extensions more
> > elegantly integrated with Radiant. But I'm hoping to appeal to any
> > skinny-controller philosophy-followers as well.
> >
> > thoughts?
> >
> > Jacob
> > ___
> > Radiant mailing list
> > Post: Radiant@lists.radiantcms.org
> > Search: http://radiantcms.org/mailing-list/search/
> > Site: http://lists.radiantcms.org/mailman/listinfo/radiant
> >
> >
>
> ___
> Radiant mailing list
> Post: Radiant@lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Radiant Core Dev: Page Controller
Hey,
I just read this post:
http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers
And it made me think immediately of the old handle_new_or_edit_post in
page_controller
http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/page_controller.rb?rev=57
But now I go and look at the latest version, and I see it's been
cleaned up a bit, and there a new AbstractModelController seperating
the logic a bit.
http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/page_controller.rb
and
http://dev.radiantcms.org/radiant/browser/trunk/radiant/app/controllers/admin/abstract_model_controller.rb
But still... you have a lot of logic in the controllers. And a lot of
that logic, if moved to the model, would be a lot easier to override
and modify in extensions.
For instance, I'd like to see all the part-creating/arranging logic
moved into the Page model.
96parts_to_update = {}
97(params[:part]||{}).each {|k,v| parts_to_update[v[:name]] = v }
98
99parts_to_remove = []
100 @page.parts.each do |part|
101 if(attrs = parts_to_update.delete(part.name))
102 part.attributes = part.attributes.merge(attrs)
103 else
104 parts_to_remove << part
105 end
106 end
107 parts_to_update.values.each do |attrs|
108 @page.parts.build(attrs)
109 end
110 if result = @page.save
111 new_parts = @page.parts - parts_to_remove
112 new_parts.each { |part| part.save }
113 @page.parts = new_parts
114 end
So, my question to the core devs is... how open would you be to patch
coming from me, that addresses some of these things.
I must admit, my agenda is based on making my own extensions more
elegantly integrated with Radiant. But I'm hoping to appeal to any
skinny-controller philosophy-followers as well.
thoughts?
Jacob
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Page attributes extensions problem with installation
it's in svn here: https://dev.eyebeam.org/svn/radiant-partatts/radiant/ details on accessing svn here: http://dev.eyebeam.org/projects/radiant-partatts/wiki/radiant-partatts On 5/24/07, Andrew Ermakov <[EMAIL PROTECTED]> wrote: > > Jacob Burkhart wrote: > > Nice to know someone else is interested... but the extension is not > > currently compatible with Radiant trunk. If you want to use it you need > > to > > use my branch of Radiant, or wait for me to port... > > And where we can get your branch? :) > > -- > Posted via http://www.ruby-forum.com/. > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Radiant Facets
The Facets model of Extensions is to break up the page editing interpace into regions and parts. To alter this interface you insert your "part" somewhere into this hierarchy. Or you can re-arrange the hierarchy. So for example you would do something like: Radiant::PageEditorUI.add "admin/page/attributes", :region => :form, :after => "edit_page_parts" Radiant::PageEditorUI.add "admin/page/popups", :region => :popups The problem with this model is that extensions don't always want to add just one button somewhere... sometimes we want to change the organization of the page editor. We want the freedom to write HTML. So I propose that instead of making this call in activate, you instead name a partial in your extension as the page editor. Ideally, you should be able to name this as the partial to use for only certain page types. something like the following declaration in my extension: Radient::PageEditorUI.define_page_editor do | user, session, default | if user.admin? 'admin/page/my_special_admin_editor' else default end end where define_page_editor is a core method that allows me to specify a block that can conditionally determine which page editor should be used. The definition of this partial (my_special_admin_editor) should be to call all the built in radiant page editor partials, and override / replace / reformat as needed So for example you would do something like: <%=page_editor_render :edit_form" do %> <%=page_editor_render :edit_title"%> <%=page_editor_render :edit_extended_metadata"%> <%=page_editor_render :edit_page_parts"%> <%=render :partial => 'admin/page/attributes'%> <%=page_editor_render :edit_layout_and_type"%> <%=page_editor_render :edit_timestamp"%> <%=page_editor_render :edit_buttons"%> <% end %> <%=page_editor_render :edit_popups" do %> <%=render :partial => 'admin/page/popups'%> <% end %> This would allow you to mix in all the HTML etc needed to properly format these pieces together for your particular setup. This would also give you the flexibility to solve the problems that will arise when multiple extensions want to change the editor. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Page attributes extensions problem with installation
Nice to know someone else is interested... but the extension is not currently compatible with Radiant trunk. If you want to use it you need to use my branch of Radiant, or wait for me to port... On 5/10/07, Artur Baldyga <[EMAIL PROTECTED] > wrote: > > I've downloaded from > > http://dev.eyebeam.org/projects/radiant-partatts/wiki/radiant-partatts > > page_attributes extension. I received two folders "extensions" and > "radiant". In "radiant" folder i found page_attributes extension so > copied it to my radiant extension folder and followed with instruction > form README file from "page_attributes" folder. > > I made first four steps. When I made: > > 5. run "rake db:migrate:extensions" > > I received error: > > no such file to load -- > /usr/lib/ruby/gems/1.8/gems/radiant-0.6.1 > /vendor/extensions/page_attributes/app/models/page.rb > > I checked this folder and excatly, there is no such a file page.rb. So I > was confused. I have wrong(not full) version of the page_attributes > extension?? > Do someone know what can be the problem?? > For help I'll be thankfull! > > -- > Posted via http://www.ruby-forum.com/. > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] How does Radiant help you make a living
Hi everybody, I've been quite busy at work lately working on an implementation of Ektron's .Net CMS. And wishing that I was using Radiant. And wishing that I had more time to work on my Page Attributes extension, and wishing that I had more time to put together and submit an irresistible patch to bring facets -like functionality into trunk. (and versioning, and and write an in-place editing extension, etc... etc..) Anyway, I was wondering, how do the rest of you do it? Are most of you contractors implementing Radiant for some small client? Are you using Radiant for your own personal Blog? Are you implementing Radiant for free for a friends site (like I am)? Basically, what's your collective advice on how I could get paid to work with Ruby on Rails and specifically Radiant full-time. thanks, Jacob ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] .htaccess for pages?
You might try putting your directive directly in the root .htaccess file and then scope it down to /staff example, put something like: AuthType Basic AuthName "Password Required" AuthUserFile /somewhere/staff.htpasswd Require valid-user somewhere BEFORE the call to: RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] As soon as Apache has called dispatch.fcgi, it's Rails handling everything, and nobody is checking your htaccess On 4/11/07, Michael Jones <[EMAIL PROTECTED]> wrote: > Hello- > > I'm having a problem getting .htaccess to work on an area of my site. > Is anyone else using a .htaccess file to protect certain directories on > their radiant sites? > > I have a secondary level page called 'staff' > > http::/somesite.com/staff > > I created a directory 'public/staff' and placed a .htaccess file in > there. > > The .htaccess file is not working. Is it possible to do this? Are there > some other things I need to change? > > Thanks- > Michael > > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] doing forms -- thinking way outside the box..
Looks pretty spiffy mike. I would be interested in getting ahold of your code. I was planning on doing the same thing, for Kupenda. (currently http://www.kupenda.org/ and http://kupenda.jotapajaro.com/) that is: Having a Radiant site for the CMS and content Having a seperate Ruby on Rails sponsorship site for managing users (with forms, and more...) I was going to go with the low-tech/hard-coding of sharing a design and linking between them... but if you've got something good for me to start from, I'd love to take a look at your code. thanks, Jacob On 4/6/07, orff <[EMAIL PROTECTED]> wrote: > (continued - hit tab enter ;-) > > 1) We needed to launch our new website lighthouse.org > 2) We needed complicated forms: > - donations forwarding to payflow link > - location based search, google maps integration > - GOOD AR validations, I love rails validation and didnt want to have to > write a rediant behavior. > > What I really wanted was radiant for the 'static' content and uninhibited > rails for the forms and apps. This allows me to do anything I want for > forms, searches, etc. > > Here is our solution in a nutshell -- 2 environments: > 1) radiant with a snippet for the other environments url ( lighthouse.org ) > 2) rails with some custom code to render pages from the other environment ( > forms.lighthouse.org) > > To see a demo, go to the site and click 'Help Near You' or 'Donate', then > 'Donate Online' > > If anyone is interested in the source code, I will happily share it. I am > not sure how well this could translate into a gem or a plugin though since > it is essentially a standalone app. > > Here is a snippet of a controller in the forms server environment, so you > can see how easy it is for us to create forms now and still use radiant for > the layout: > > class DonateController < ApplicationController > > def index > redirect_to :action => 'new' > end > > def new > @event_name = 'Online Donation'## label used on forms and in the > controller > > @form_var_name = 'donation' ## used in the shared/_contact form > partial which gets called in the new view > > if event_params = @params['donation'] > @donation= OnlineDonation.new(@params['donation']) > > ##SET EVENT TYPE -- DIFFERENT FOR EACH METHOD -- event_type > field in the Database > @donation.event_type = 'Online Donatation' > > #raise @event.inspect ## dubugging for checking before > submitting > if @donation.save > flash[:notice] = @event_name + ' was successful.' > redirect_to :action => 'success', :id=>@donation.id > else > flash[:error] = @event_name + ' could not be accepted.' > @radiant_html = process_radiant_layout( :page_id=>40, > :title=>'Donate to the Lighthouse') ## in application.rb > render_text @radiant_html > end > else > @radiant_html = process_radiant_layout( :page_id=>40, > :title=>'Donate to the Lighthouse') ## in application.rb > render_text @radiant_html > end > end > > def success > @event = OnlineDonation.find(@params['id']) > @radiant_html = process_radiant_layout(:page_id=>40, > :title=>'Thanks') ## in application.rb > render_text @radiant_html > end > > end > > the process_radiant_layout method is in the application.rb. What is does is > connect to the radiant database and process all of the tags using recursion, > then uses the local view in place of the content. So the local view for the > new action will be just like and rails app. The main difference is we dont > use rails layouts, we have code to render a specific radiant page's layout > (redirecting all links back to the other environment). > > -mike > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Future Development of Mental Radiant
John (and core), If there's anything I can do to help with Mental (especially related to the fate of Facets)... Please let me know Jacob On 4/3/07, John W. Long <[EMAIL PROTECTED]> wrote: > Benjamin Minton wrote: > > Just wanted to ask, how long will Mental continue to be developed before > it > > is extended sufficiently to require a complete new SVN checkout or version > > release (ie 7.0)? I am trying to decide whether to continually update (say > > once per week my Mental Radiant) or freeze it? > > I'd really like officially release 0.6 soon. We have a few more items to > work on before it's ready for public consumption, but I'm afraid that > work, taxes, and a stomach virus are keeping me pretty busy right now. > > I don't anticipate any major changes between now and the official > release. So you are probably fine running on edge as long as you keep an > eye on the change logs. > > -- > John Long > http://wiseheartdesign.com > ___ > Radiant mailing list > Post: Radiant@lists.radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant replace Pages with Abstract Content Model
Oliver, Might I suggest you write up a proposal of sorts on wiki. We can all help you refine it, but let's propose something concrete about the strucutre of the "abstract models" from which Pages, Layouts, Snippets, and "future content types" should be based. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Presentation video
>From the presentation: 0.7 - Intaglio (Blogging) Comments, tagging Mars Edit support Convert from WordPress, Typo, Mephisto Robust import/export Oh? Where can I learn more? Is there a planned future release to address what's being discussed in the "Radiant replace Pages with Abstract Content Model" thread? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant replace Pages with Abstract Content Model
What about also unifying Snippets and Layouts under a single abstract model? In which case this is no longer true: > Actually the commonality is: > > - available through a url > - updates the response The commonality is simply "user editable content" If Pages, Snippets, and Layouts all made use of the same underlying "content" model, then this would give additional flexibility to extension authors to write other kinds of "content" also using this model. For example: "Spotlights". I can imagine an extension for managing a collection of spotlights and setting up rotating spotlights, (And it could even do things like manage banner ads) But underneaeth it should use the same Model and the same R:tags that Sinppets, Layouts and Pages use. And that model should be called Content. Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Idea: Other form elements during input
Andrew, I suggest you check out: http://dev.eyebeam.org/projects/radiant-partatts/wiki This extension/hack of Radiant gives all your pages an "attributes" tab where you can add named strings, bools, links, and files... (and then reference them from r: tags) Andrew Klein wrote: > Hello all! > > Been a while since I've pestered you all, and I've been working on my > site a lot. I did come up with an idea that would improve my life and > likely many others. Right now, Radiant's input is essentially a big text > box and multiple parts/sections capable. Now, here is my thought; I tend > to have some 'common' options throughout my site, and it'd be easier to > do a radio button selection, or check boxes, or similar. Also, there > are some common links I tend to use. Right now for some of it I use > either the existence of certain tabs or data within certain tabs to > support this. Here's the thought > > For tabs, instead of allowing straight text, why not allow the building > of 'options' pages. IE:- There'd be 'body', 'extended', and 'options', > and options would be inherited from parent for ease of adding it, and it > would be a list of options and variables. For example. I do reviews. I > have three styles of reviews right now: Full (Normal) review, Quick > overviews and Follow-Up reviews. I'd love to have a radio button set > that I could set up that it'd change some of the underlying structure > (Which is commong between them all) based on which is chosen. You could > (I'm not) also be able to make a short text entry box for a rating > 'number' that'd show up in a floating div to the side of the review, or > a check-box to allow an image to show up 'Me-Approved!' > > On top of this, you could also eventually add image and file support > including an uploader. This would be extremely handy if you have a > common screenshot div that you'd like to just add quickly. Allow you to > select from a server-side location for the file or an automatic > uploader. > > Ideas or suggestions? I know I may be vague, but it was my brainstorm > this morning on how to extend Radiant. > > Thanks! > BladedThoth > (Andrew Klein) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Table 'radiant_dev.config' doesn't exist
Attempt to connect to your radaitn_dev database manually and confirm that the config table exists. Do any tables exists? Perhaps you need to re-run the database install. or: rake db:migrate VERSION=0 and then rake db:migrate -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Conflicting updates
Yes, there will be issues with Extensions... that's why Version Control would have to be a part of the core of Radiant, and there would need to be hooks available for Extension authors so that they can decide how their page additions should be versioned. I agree, this is all very non-trivial... Finally, just because the database tables and on-save hooks are part of the core, doesn't mean that the interface to actually work with the version history, rollback, merge, etc... needs to be part of the initial feature set. (it can all be done via script/console to start) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Conflicting updates
Jacob Burkhart wrote: > Don't know if this is a good idea, just throwing it out there... > > Some CMSs use the concept of "checked out" and "checked in" content. As > soon as a user starts editing a page it becomes "checked out" and nobody > else can edit it. You can even save your changes without checking-in > the file. Then, you can display in the tree view who has what files > "checked out". And, perhaps an admin would have the ability to "force > check in" for a page. > > Basically, this is: >>> User can't even open the page because user B has that page locked >>> (opened). > > With some terminology to display to the end users. Or, Maybe it's time to consider addding versioning and history tracking. If we detect a simulatneous edit, we simply save both versions.. one of those versions is the later version and one of them is the earlier version. The User saving the later version would be notified of the conflict and be able to use the history and rollback functionality to resolve the conflict... -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Conflicting updates
Don't know if this is a good idea, just throwing it out there... Some CMSs use the concept of "checked out" and "checked in" content. As soon as a user starts editing a page it becomes "checked out" and nobody else can edit it. You can even save your changes without checking-in the file. Then, you can display in the tree view who has what files "checked out". And, perhaps an admin would have the ability to "force check in" for a page. Basically, this is: >> User can't even open the page because user B has that page locked >> (opened). With some terminology to display to the end users. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] mongrel_cluster and radiant
I know nothing about Mongrel, and I've never looked at the memory footprint of Radiant running anywhere But, just based on what I know about what Radiant DOES, it shouldn't really be taking up that much more memory than any other rails app, right? Here's my thinking: If you're not doing anything in the admin, then the work that Radiant actually does is pretty minimal. For the most part, It's just fetching cached pages. I suggest you run a "Hello World" rails app on your hosting environment, and compare the memory footprint. The next thing to consider is, what is Radiant keeping in memory? (i.e. what can you make Radiant stop keeping in memory so that you have a smaller footprint) Sesssions? is it storing anything about sessions in memory? How else can you tell what is being stored in memory? Is it just the size of the codebase that's the main factor here? If you download a buncha plugins and make sure they load into Radiant but don't do anything, does this change your memory footprint? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Help on Extension: EmbedPage
Colin Nederkoorn wrote: > The issue I am running into is that generally the application I am > trying to > load has relative references, and when it is embedded, it assumes > everything > is coming from the embedding page, and not the application... can anyone > suggest how to remedy this? as an example: You might have your Radiant at radiant.example.com, and radiant.example.com/embeddedapp calls And then the resultant page would have soemething like this Login But the problem if you then click "Login" your browser will go to radiant.example.com/embeddedapp/login when it should really be going to myapptoembed.example.com/login But the real problem you are going to have is when you Submit that login form And even it makes a POST to: - myapptoembed.example.com/login it will then redirect to: - myapptoembed.example.com/loggedin instead of coming back to some sort of Radiant equivalent: - radiant.example.com/embeddedapp/loggedin Now if all you want to do is make myapptoembed.example.com show up at radiant.example.com/embeddedapp All you really need is some Apache rewrite directives. Apache can automatically convert each url as it comes in to the right back-end url... So, the question is... what are you REALLY trying to accomplish here? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant i18n
When/Where do these conversations about "the admin UI may change" occur, and how can I get invited? Sean Cribbs wrote: > Sorry to burst the bubble, but John informed me we won't be including > i18n until version 1.0, partly because the admin UI may change > significantly between now and then. However, if you are still willing > at that time, we'll hit you up for translations. > > Sean -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] should not return virtual?
and it's because virtual is a column on the page... And so after adding def virtual? true end to my page type, I had to re-edit it to save this to the database. You can all ignore my pre-mature ramblings -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] should not return virtual?
So I figured out that if my page type includes ArchiveIndexTagsAndMethods, then it won't show in the list generated by r:children but I still can't figure out why... anybody know? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] should not return virtual?
If I use: I was thinking that it should not include FileNotFound etc.. type pages. (Pages that return true for "virtual?") Does this make sense to everyone else? I'll file a ticket with a fix, but I just wanted to check. Can you think of a use-case where you would want "virtual" pages listed along with the normal ones? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Facets branch extensibiliy extended
If you guys would like to keep up with my "usecase" for the facets changes I proposed, you can now take a look at: http://dev.eyebeam.org/projects/radiant-partatts/browse Thank you to Jaime for setting this up. Hopefully this will eventually morph into a the repository for Just the partatts extension. (And supplemental TinyMCE and FCKEditor extensions) Currently, it maintains a full version of radiant (modified facets) as well. I am more interested in making the Radiant a powerful platform, than I am in simply getting my changes checked in to core. If you guys can come up with a better API for supporting multiple page editors, I'll be happy to port my extension over to use it. Using my API as a base, and improving it. Is also a possibility I encourage. Also... perhaps we should come up with a convention for extension including static files. It's no big deal to have to copy the fckeditor javacripts into public to get the extension to work, but perhaps there should be an official standard. public/extensions//etc... for example. Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] API through XML-RPC (was: Re: JS-free v iew ? (newcomer))
What's the basic idea behind making a JS-free view? Is it for users with text-only browsers? Why not take the approach of making sure that all of the features of the admin be easily supported through script/console. For instance, we already tell people to use script/console to edit the Conf. Would some API improvements like this meet your needs Boris? What if you built an extension that just added a bunch of utility classes/methoda that made it easier to build a site directly from script/console? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Facets branch extensibiliy extended
My use case for needing more than just a hook on page.attributes= is for when page has_many My extension adds: has_many :page_attributes, :class_name => 'PageAttribute', :dependent => :destroy I need to capture each page_attribute that was added or deleted, similar to the way page parts are managed. (But as I said, I've just overriden handle_new_or_edit_post for now..) Also, I think I can understand not wanting to add _edit_select_editor.rhtml to the core. As long as you maintain the usage of page_helper's: def editor_ui if(flash[:page_editor_ui]) to_return = Radiant::PageEditorUI.editors[flash[:page_editor_ui]] end unless to_return and to_return != nil to_return = Radiant::PageEditorUI.editors[session[:page_editor_ui]] end if to_return.nil? Radiant::PageEditorUI.editors.default else to_return end end I can always make _edit_select_editor a part of my extension and add to every editor during extension loading. And most extensions can set flash[:page_editor_ui] for "simple" usecase. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] radiant on dremhost - incomplete dispatch.fcgi headers?
Ohh, good to know that the memory limit is tied to the user account. I'll have to start creating new users for each new site I setup. I did notice one time my radiant on dreamhost crapped out while I was doing a lot of intesive admin work. And it repeatedly failed to restart after that for about 15 minutes... And then eventually it was fine again without me doing anything. I wonder if the memory limit is due to some extra startup logic or checking etc... What's the first page you hit after killing all the crapping out fcgis? This might make a difference. I'd think the best thing to do is hit a page that is already cached before hitting the admin. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] radiant on dremhost - incomplete dispatch.fcgi headers?
Do you see any other information in other log files? As a test, try creating a fresh "empty" rails project. Can you run >> rails testproject on the dreamhost ssh command line See if you can get an empty rails site running. Then compare the dispatch.fcgi and environment.rb of the test project with the radiant you are trying to run. Also try installing radiant as a full standalone app instead of using the gem. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Adding parts the easy way (KISS-GUI)
Nifty Idea, I wonder how we could make this more "automated" to provide some layout information about what page parts of being used for a given arbitrary page. (Not one using your specific layout) Perhaps a temporary override http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Facets branch extensibiliy extended
How have I specifically hurt the simple use cases? Is there some compromise we could make that would still give me a hook to have multiple editors? My code may be a little less elegant, but I don't think it's obtrusive. The editor you didn't see in my original submissions (but is in v5) is the "content" editor. This is an editor with some features cut out which is specifically setup for a "content" person to use. It's only supposed to show the partials that use can edit, and it hides things like layout and page type. You can look at this editor in my v5 attachment. I tried your suggested approach of having fck or tinyMCE load directly into the current page structure. The problem with this is that it's too slow to use in practice. Both WYSIWYG editors take significant time and bandwidth to load, and reloading them each time you tab between page parts was unacceptably slow. Additionally, I couldn't get tinyMCE to work in Safari within the TabControl currently being used. It has to be done the way I did it. (One WYSIWYG loads and the contents of the parts are swapped in and out of it by the tabs) The other reason for making facets support multiple editors is for compatability. If there starts to be multiple extensions that alter the page editor they can start to conflict. The easiest way to avoid conflict is for each to define it's own editor. I think it makes writting extension a little more elegant too because you define all of your page editor modification in your class which subclasses DefaultEditor instead of having to define these changes in "activate" Looking to the future, imagine very specific page types. A "calendar" page type for instance. You don't want to edit the calendar page with the current editor, you want to edit it with a customized editor from the calendar extension. And you don't want all your page editors to be calendar page editors. And your calendar editor should still re-use components from the standard page editor, and still post to the page_controller. This is the more "long term vision" problem I am attempting to solve. I'd like to further extend my work so that handle_new_or_edit_post in PageController makes a call to some method of the editor_ui as a hook for doing saving or whatever on whatever your editor has added to the page. (In my case it's page_attributes, and currently I'm just overriding handle_new_or_edit_post) In my latest version of facets, it's possible to set flash[:content_editor_ui]. If it is set, then it will use the editor specified just for the current page edit. (And revert back to whatever editor you have saved in your session for other pages) I realize that: Radiant::PageEditorUI.editors.default isn't as elegant as: admin.page.edit_partials I had envisioned doing something like: admin.page_editors.default This would be more consistend with the currently accepted admin.tabs. method of adding tabs, But my ability to understand and debug dependencies loading failed me. What else are you objecting to? Please suggest how I can improve my code to support multiple editors without complicating the simple usecases. On a side note, I've found Radiant::ExtensionLoader::do_after_activate_extensions do end to be usefull for more than just setting up multiple page editors. I've found that getting dependencies to load in the proper order can be very tricky, and this provides another hook for fiddling with the loading order of things. (In my case, I had to load my extensions to PageController in this block or I would get loading problems) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] default options
Jacob Burkhart wrote:
> def show_page
> response.headers.delete('Cache-Control')
> url = params[:url].to_s
> show_uncached_page(url)
> end
This will also show pages that have "Draft" status.
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] default options
You can also disable caching permanently by modifying the show_page
method of the SiteController
def show_page
response.headers.delete('Cache-Control')
url = params[:url].to_s
show_uncached_page(url)
end
I recommend leaving the original code for show_page there and commented
out, and making sure you put it back to normal when you go to a
production environment.
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Facets branch extensibiliy extended
Another dump of my "current" radiant setup is available for those who are curious http://jotapajaro.com/dump/facetsv5.zip Waiting on Sean to react to my first round of facets changes before I dump any more changes on him... I welcome all critiques of my code. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] child should inherit
Jamie, I'm trying to solve the same problem with a different solution. I've created what a "TemplatePage" type, and all page parts have a checkbox for "is_template". You can then have quicklinks like you described "New Blog Post" that would create a new "ContentFromTemplatePage" using the "Blog Post" template page as it's base. Only parts that are marked with "is_template" will exist in the newly created page. If a part is referenced in the context of a ContentFromTemplatePage and it doesn't exist on that page, then the TemplatePage is was created from will provide this part. That way you can use the "body" part in your TemplatePage "Blog Post" to define the layout of the post. And then have is_template parts "teaser" and "extended" that contain just straight text content. new "Blog Post" items will be created with a "teaser" and "extended" part (and no body). And when the layout refers to it will pull the formated body part from the TemplatePage it was created from, and when that body refers to "teaser" and "extended" parts it will show the content you entered for your particular blog post? Make sense? This and a number of other things, like TinyMCE, FCKEditor, and pages attributes (which inherit in the same way that parts do from TemplatePage). Will be part of an upcoming extension currently being called the PageAttributes extension. There's only 1 catch. I'm relying on changes I made to the facets branch which havn't been accepted by the core devs yet. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Searchable tag reference
John W. Long wrote:
> Very interesting. Can you clean up the Javascript so that it uses the
> built in prototype.js functions?
What sort of cleanup did you have in mind?
I just learned the other day (after I had already written this) that you
can find elements like this:
$$('div.tag-reference')
I could use that to replace my getAllDivsOfClass
Did you see any other places where Prototype could help?
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Defining new page types in an extension
/Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:266:in `load_missing_constant': uninitialized constant StandardPage (NameError) from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:452:in `const_missing' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:464:in `const_missing' from /Users/igotimac/radiant_svn_v2/facets/radiant/vendor/extensions/page_attributes/app/models/content_from_template_page.rb:4 from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:203:in `load_file' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:202:in `load_file' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:94:in `require_or_load' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:248:in `load_missing_constant' ... 12 levels... from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../vendor/rails/railties/lib/initializer.rb:43:in `run' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/../lib/radiant/initializer.rb:32:in `run' from /Users/igotimac/radiant_svn_v2/facets/radiant/public/../config/environment.rb:10 from /Users/igotimac/radiant_svn_v2/facets/radiant/public/dispatch.fcgi:21 -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Defining new page types in an extension
What's the best way to define new page types in an extension? I created some classes that extend StandardPage, but they aren't loaded. (Don't appear in the page type drop-down) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant 0.6 RC1
> tried to use dreamhost's standard apache/fcgi, the application didn't > start, getting the application error "Rails application failed to > start properly" and nothing on the logs. What do your logs say? Check both the standard Dreamhost-provided log directory as well as radiant logs. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Searchable tag reference
Now in Trac: http://dev.radiantcms.org/radiant/attachment/ticket/481/searchable-tag-ref.diff -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant 0.6 RC1
John Joyce wrote: > If installing your own local RubyGems on DreamHost, shouldn't you > install a local Ruby? or no? > I've personally struggled to get Radiant going on DH!!! Always a > BlueCloth dependency error. Says not installed. But it's there, PATHs > are set. Since then, deleted all. Maybe I'll try again. > Would be nice to have a full, detailed, step-by-step for DH and Radiant, > starting from nothing. I'm not having any trouble running Radiant on DreamHost. But I think I'm running in application mode, not instance mode. All I had to do was get latest of Mental and upload it to my host. (make sure fastcgi is turned on) Then create a symbolic link from http to the public directory in radiant. Then everything except the database should be working. If you're still having problems, try messaging "igotimac" on irc.freenode.net#radiantcms -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] problem getting radiant-mental with custom extension wor
It's always the simplest solution isn't it... I needed to do: def self.included(base) Instead of def included(base) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] problem getting radiant-mental with custom extension wor
Sean Cribbs wrote: > > class << Page > has_many :widgets > end > > -or- in the `included` method of your module do a class_eval, > > def included(base) > base.class_eval do > has_many :widgets > end > end > > You could also use `send` to invoke the has_many method. In other The first 2 methods don't work at all. I get undefined local variable or method `inherit_from_page' for # Using the first 2 techniques, where I'm adding a: belongs_to :inherit_from_page, :class_name => 'Page', :foreign_key => 'inherit_from_page_id' Using the third technique (explicit send calls) It actually "works" for the first page load, and then fails on subsequent loads. What I think is really messing things up is rails trying to automatically load things. I have rails in dev mode, and it reloads changes to certain files, and not to other files. I havn't been able to figure it out, but my suspicions is that the way files are loaded at startup is different from the way they are automatically reloaded. I've been trying to look through the source attempting to figure out exactly how extensions are loaded. If someone familliar with the subject would hop on irc.freenode.net and talk to igotimac about it... I would greatly appreciate any help. thanks, Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Facets branch extensibiliy extended
Hey Sean,
Here you go... : )
http://pastie.caboo.se/41244
(also at: http://jotapajaro.com/dump/facets.diff)
I implemented the "for_all_editors" I was talking about aboce...
Here's the example of usage from page preview extension;
+Radiant::ExtensionLoader::do_after_activate_extensions do
+ Radiant::PageEditorUI.each_editor{ |editor| editor.add
"preview/preview_button", :region => :buttons }
+end
Let me know if you have any questions,
I'm eager to see the changes I'm now relying on "officialy supported"
Jacob
--
And for anybody else who's interested the latest version of my changes
along with TinyMCE and FCKEditor extensions is available at
http://jotapajaro.com/dump/facetsv4.zip
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Weird Extension stuff on Deployment
First, make sure that your App is in production mode in environment.rb.
If that doesn't solve everything, then you can force things to work with
explicit "load" calls:
i.e.
load
"#{RADIANT_ROOT}/vendor/extensions/page_attributes/app/models/page.rb"
Try putting an explicit load call to your events controller at the end
of your extension definition. (or at the end of some other controller in
radiant core).
Yes I know this is a hack, but it's quick and dirty...
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Facets branch extensibiliy extended
> I've made it:
> Radiant::EditorUI.editors.default.add "preview/preview_button",
> :region => :buttons
>
> My TinyMCE is added via:
> Radiant::EditorUI.editors.add(TinymceEditorUI.new)
And now that I've got that working. (You page preview extension works
properly) I could probably change it to:
admin.editors.default.add "preview/preview_button", :region => :buttons
and:
admin.editors.add(TinymceEditorUI.new)
I just had to make it a seperate class because I was getting confused
with PageAdmin being defined inside of AdminUI. I've defined a seperate
file editor_ui.rb that sort of copies what admin_ui.rb does for admin
tabs to enable the user-selection of page editor.
I was also thinking I might make something like this work:
admin.editors.for_all_editors{ |editor| editor.add
"preview/preview_button", :region => :buttons }
Where we use a block so we can save the block until all extensions have
loaded and added whatever editors are going to be added. And then once
it's all loaded we can execute all the blocks that were passed via
"for_all_editors".
With some exception catching. (In the above example if an editor has
already had it's :buttons region removed we can't add
"preview/preview_button" and we should just fail silenty, unless perhaps
there are no editors that this block executes successfully for)
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Facets branch extensibiliy extended
Hey Sean, (and anybody else interested in facets) I've further refactored facets, and refined my TinyMCE extension (whick takes advantage of that refactoring). Instead of: admin.page.edit_partials.add "preview/preview_button", :region => :buttons I've made it: Radiant::EditorUI.editors.default.add "preview/preview_button", :region => :buttons My TinyMCE is added via: Radiant::EditorUI.editors.add(TinymceEditorUI.new) Where TinymceEditorUI is a subclass of Radiant::EditorUI::DefaultEditor I've zipped up the entire thing and made it available at: http://jotapajaro.com/dump/facetsv2.zip Please check it out, let me know what you think. Let me know if you think I'm going in the right direction. Let me know if you have any questions. What's the best way to get in touch with the Radiant core team directly? I'd like to discuss my ideas. thanks, Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] (Finally) Launching my Radiant site
Hey Daniel, I'm curious, what's your hosting setup? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] open source cms sumit
Sean Cribbs wrote: > If it were only this coming weekend and not a month from now... I'd > love to show those Drupal guys how Radiant rox their sox. Why not submit a proposal Sean? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] facets branch? (Look everybody, a WYSIWYG)
> There's the overview. Again, what I'd like is feedback on the API -- is
> it easy enough to use, what pitfalls are there, how can things be
> refined, etc.
Thanks Sean,
I've just spent a day with Facets, I'd like you to take a look at
http://jotapajaro.com/dump/facets.zip (8.8 MB)
The ability to add/remove parts of the editor interface, and override
specific parts is really very powerfull. And your code is well written.
(better than mine)
I was thinking... There are times when you want your extension to
provide an alternate page editing interface as opposed to overriding the
existing one. For example, If we want to add a WYSIWYG to Radiant.
Well I just wipped one up as an extension, and I went through great
pains to make sure this time it wasn't a complete hack. This time, I
tried my best to modify the core of Radiant (facets branch) to support
any sort of extension that wants to provide the user with a choice of
editor. (as opposed to replacing the existing editor)
Unfortunately, it looks like whenever my WYSIWYG extension is loaded
your page preview extension doesn't work. But I don't think I messed
things up too much, because if I remove my extension (and leave my core
changes) then page preview works again. So my approach may need a little
tweaking, but I think I've got a pretty good idea for the approach here.
I've set it up so that in extension.active I can say:
admin.editors.add("Tinymce", TinymceEditorUI)
Where TinymceEditorUI is a class defined like this:
include Simpleton
class TinymceEditorUI < Radiant::EditorExtension
def initialize
super
#Don't display the tabControl of page parts, instead display TinyMCE
self.edit_partials.regions[:form].delete("edit_page_parts");
self.edit_partials.add "tiny_mce_editor", :region => :form, :before
=> 'edit_layout_and_type'
#Need to add an "onsubmit" action to the page edit form
self.edit_partials.delete('edit_form');
self.edit_partials << 'mce_edit_form';
end
end
Please, take a look, refine what I've done, and if you like it -- check
it in!
thanks,
Jacob
P.S.
Also, I'm creating tabs manually in my interface (instead of using the
TabControl javascript) and they don't look as good. Does anybody know
what the HTML that the TabControl javascript generates looks like?
(take a look at my code an see if you can fix it?) If only I could view
source of the TabControl generated DOM
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Why don't I see anything logged for rake db:migrate:extensio
It took me the longest time to figure out that my extension migration WAS actually working when I ran: rake db:migrate:extensions Is there a reason I don't see the log of tables being created etc when I run this? Can this be changed? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Errors checking out from SVN
I tried to checkout the latest of the facets branch and I get this error: Fetching external item into 'facets/vendor/radius' subversion/libsvn_ra_svn/marshal.c:255: (apr_err=210002) svn: Connection closed unexpectedly any ideas? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] facets branch?
I just noticed a facets branch in svn. What's the goal of this branch? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Searchable tag reference
Ok I really want to submit this to the Mental branch please
Can somebody explain to me how to upload files with a ticket?
I decided that the tag reference was too long to scroll through, so I
added a search box to it.
To use my search box, modify edit.rhtml like so:
===
--- edit.rhtml (revision 326)
+++ edit.rhtml (working copy)
@@ -190,7 +192,12 @@
<% end %>
-Available Tags for <%=
@page.class.display_name %>
+
+ search tags:
+
+
+ Available Tags for <%=
@page.class.display_name %>
+
<%= tag_reference(@page.class.name)
%>
<%= link_to_function 'Close',
"Element.hide('tag-reference-popup')", :class => 'close-link' %>
This will add a search box and include my div_text_search.js (seperate
file)
Which you can grab here:
http://jotapajaro.com/dump/div_text_search.js
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] extending
> Each of the apparent child pages of that page are actually a single > virtual page that uses the passed URL to determine which collection of > models to display. So you are using a custom page type for that? Can I see the source please? : ) -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Making url pararamters available from tags defs
>> I have tried to modify the
>>
>> tag to accept a passed variable that tells it what the current offset is
Assuming you are using mental, apply this diff to site_controller.rb:
Index: site_controller.rb
===
--- site_controller.rb (revision 326)
+++ site_controller.rb (working copy)
@@ -13,11 +13,12 @@
def show_page
response.headers.delete('Cache-Control')
url = params[:url].to_s
-if live? and (@cache.response_cached?(url))
+extra_params = params.reject{ | key, value | ['action',
'controller', 'url'].include? key }
+if live? and (@cache.response_cached?(url)) and extra_params.empty?
@cache.update_response(url, response)
@performed_render = true
else
- show_uncached_page(url)
+ show_uncached_page(url, false)
end
end
@@ -28,11 +29,11 @@
found if found and (found.published? or dev?)
end
-def show_uncached_page(url)
+def show_uncached_page(url, cache_result=true)
@page = find_page(url)
unless @page.nil?
@page.process(request, response)
-@cache.cache_response(url, response) if live? and @page.cache?
+@cache.cache_response(url, response) if live? and @page.cache?
and cache_result
@performed_render = true
else
render :template => 'site/not_found', :status => 404
This will change site_controller so that any reuqest containing url
parameters ?like=this&and=that will not be cached.
Now, you can reference the request parameters from within your tags:
here's an example that just prints out the parameters:
desc %{
hi
}
tag 'hi' do |tag|
out = ""
tag.globals.page.request.params.each do
| param |
out += param[0].to_s + ": " + param[1].to_s + " "
end
out
end
John (and Core)
I tried to submit my diff as a ticket to Trac, but I don't see any way
of uploading it via new ticket... what am i missing?
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] extending
bueller wrote: > So i am trying to make a way to list the previous articles in a list > format not by date or month but simply by order published, also be able > to break that up into multiple pages (page one is 12 articles page 2 is > 12 and so on) in a dynamic fashion. I have tried to modify the > > tag to accept a passed variable that tells it what the current offset is > but that has been to no avail i dont care if its by passing a variable > or by using tags or making a new behavior i just want a simple page that > lists all my articles in order dynamically allocating how many articles > can be viewed per page have you tried mucking with definition of the r:children tag? are you using trunk or mental? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] New Extension for Mental!
I have completed version 001 of my extension. It is available at: http://jotapajaro.com/dump/page_attributes.zip Be sure to read the README to install, there are some things I wasn't able to do perfectly with the extensions system so I've detailed a few small changes to make to radiant core in order to support my extension. These changes reflect a need for some sort of mechanism extensions can use to alter the page edit screen. (They are NOT changes I'm suggesting for checkin to mental or trunk) -- Details of the features of my extension. -- This extension adds an "Attributes" tab to the edit screen of every page. You can add named attributes of different types and assign them values, and then do things based on these attributes with r:tags. The available attributes are: UploadedFilePageAttribute: Allows you to upload files for a specific page, and then reference them with the tags: StringPageAttribute Allows you to define content in short strings in addition to page parts. can be referenced with that tag: BooleanPageAttribute Allows you to add a named checkbox to particular page, then check/uncheck it to control the output of these tags: ... ... PageLinkPageAttribute Allows you to specify the url of another page on the site. (Or select the url from an auto-completer after typing in a portion of the page's name) You can then reference linked pages with the tag: ... -- More Features -- I have also added a thing called "Inherit From Page" to this Attributes tab. Specifying a page in this box helps to eliminate some duplication of code. During page rendering, if a page part referenced by a tag is not found for a particular page, then the "inherits from page" link is followed and that page part if retrieved from the parent if available. If you are looking through my source, please note that there are more features I intend to provide with this extension, and they are not all fully implemented or explained in this release. (But, also they shouldn't break anything else...) I look forward to a discussion with the Radiant Core team about what could be done to both Radiant and my Extension in order to support it without the hacks explained in the README. thanks, Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] My notes/ideas on Page editor extensions
I really mean to write this for myself. But if I write it here then maybe it will be of use to someone else as well. I've been working on moving the additions I made to Corex into extensions for Mental. I've added a lot of functionality (and plan to add more). To the page edit screen. I have an idea from an interface perspective. Imagine a set of tabs aligned vertically along one of the side of this page edit screen. The main tab contains the existing Page edit screen. Extensions could add tabs to this page edit screen. For instance, there might be a tab for using a particular WYSIWYG editor For instance, there might be a tab to manage comments on the Page being edited. (as in the case of a blog post) This tab might only appear for certain page types. I my case: There will be a tab to manage all of the Page Attributes of a page: A Page can have a number of named attributes. There are different types of attributes such as UploadedFileAttribute, and different tags for referring to them (i.e. would output an image tag referencing the file that was uploaded as the "logo" attribute) There will be a tab for managing which parts of a page are layout oriented. (contain multiple radius tags) And which parts of a page are content oriented. (These parts are the parts that a client of an already setup CMS would be interested in) Also in this tab, you can manage an attribute called "Inherits from Page", in which you can select any page as the parent page. (Not parent as in site hierarchy, but parent as in template) If a particular tag does not resolve on a particular page. (i.e. there is an but there is no "header" page part) Then the processor should look for and use a page part from the "parent" page if it is available. Inherits from page supports 2 new page types (Selectable from the normal page edit interface). TemplatePage and ContentFromTemplatePage. A shortcut will be made for creating new ContentFromTemplatePages based on an existing TemplatePage. The new page will have only the page parts that were marked as "content oriented" on the TemplatePage it inherits from. There will be a tab simply for editing those page parts that have been marked as content oriented. This tab would be displayed in place of regular editor tab for TemplagePage typed pages. This means I intend to submit a ticket with the changes to core to support an ability for extensions to add these page-editor tabs... if I ever get around to it... If anybody else is interested in helping me develop (the code or the interface) for these half-coded ideas, let me know and I'll send you my hacked up version of Corex. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] problem getting radiant-mental with custom extension wor
> loads extensions -- routes and classes load in the right order. It seems > as > if what you want is to mix a module into Page, rather than redefining > the > class. I'll be on IRC today if you would like assistance. > > Sean Thanks for the offer Sean, what about this weekend? It looks like I will take the approach discussed above of submitting some "example" extensions that demonstrate my problems. Sean, your idea to mix in a module work for adding methods to page, but breaks for things like has_many and belongs_to -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Metal vs. 0.6.0
> creating extensions it would be nice to be able to do it in instance > mode. Can somebody tell me what "instance mode" and "application mode" are? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] problem getting radiant-mental with custom extension wor
I too am having issues like this.
I solve them temporarily with explicit "load" calls in various places
i.e. at the end of page.rb in core I added
load
"#{RADIANT_ROOT}/vendor/extensions/page_attributes/app/models/page.rb"
My hope is that I'll be able to complete my extension with a bunch of
these hacks, and then go back and figure out a way to make it work
properly. I have a feeling the way that Radiant currently loads up all
extension code is insufficient, but until I have a completed working
extension I can't completely narrow the blame. I suspect there are
changes that should be made in Radiant Core code, but I can't
rationalize them until I have an extension that demonstrates the need.
Also, I noticed sometimes routes.rb gets loaded befor routes defined in
my extension. Which leads to all URLs generated resolving to
site_controller.
(due to :site.connect '*url', :action => 'show_page' )
So I actually added a line just before the site controller stuff so that
I would have a generic route for everything:
map.connect 'admin/extensions/:controller/:action'
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can you use controllers/views within a tag
Jason, can you clarify what you are trying to do a little more? You seem to be asking multiple questions at once. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] How does class loading work!?!
> I have just checked in some additional tests that show extension > routes working fine. I also created an extension, put in a custom > route, generated a link using url_for, and have no problems. A couple > of comments below: thanks Adam I think things may be messed up in my case because I'm trying to add functionality to the page edit screen. I did this by directly editing page/edit.rhtml (in core radiant) and adding: <%= render :partial => 'attributes' %> But that partial exists only in my extension. This works, but I get the exception the second time _attributes.rhtml is loaded (via a page edit). I was thinking this would just be a temporary hack to make sure things work, and then later I would figure out how to enable the registering of a tab with the Page Edit interface just like you can register a new tab for the overall admin interface. So, so far I'm stuck here, but maybe I'm taking the wrong approach to modify the page edit screen. Any other suggestions? thanks, Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] How does class loading work!?!
> I'm getting more bizzaro behavior with my extension now relating to
> loading.
my stacktrace
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/routing.rb:1252:in
`generate'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/url_rewriter.rb:104:in
`rewrite_path'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/url_rewriter.rb:69:in
`rewrite'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/base.rb:522:in
`url_for'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/helpers/url_helper.rb:27:in
`url_for'
/Users/igotimac/radiant_svn/mental/radiant/vendor/extensions/page_attributes/app/views/admin/page/_attributes.rhtml:116:in
`_run_rhtml_47vendor47extensions47page_attributes47app47views47admin47page47_attributes46rhtml'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:326:in
`compile_and_render_template'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:301:in
`render_template'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:260:in
`render_file'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:275:in
`render'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:59:in
`render_partial'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:26:in
`benchmark'
/usr/local/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/local/lib/ruby/1.8/benchmark.rb:307:in `realtime'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_controller/benchmarking.rb:26:in
`benchmark'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/partials.rb:58:in
`render_partial'
#{RAILS_ROOT}/vendor/rails/actionpack/lib/action_view/base.rb:287:in
`render'
#{RAILS_ROOT}/app/views/admin/page/edit.rhtml:125:in
`_run_rhtml_47app47views47admin47page47edit46rhtml'
Anybody know what the deal with the weird 47s is?
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Adding methods to Page from an extension
> Page.send :include, NewPageMethods That's the magic I was looking for thanks. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] How does class loading work!?!
I'm getting more bizzaro behavior with my extension now relating to
loading.
In this case, a routing declaration is working the first time, and then
failing on the second try.
My partial calls:
url_for(:controller => 'page_attributes', :action => :add)
the first time it loads, and things look ok. (after a fresh server
restart)
But then when I go to another page and come back I get a:
No route matches {:controller=>"admin/page_attributes", :action=>"add"}
I'm defining my route by doing:
define_routes do |map|
map.connect 'admin/page_attributes/:action', :controller =>
'admin/page_attributes'
end
at the top of my extension (like the other ones do)
Can somebody please explain something about the magic that loads
extensions.
Apparently something is working when the extension is first loaded and
then fails when it is re-accessed.
thanks,
Jacob
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Adding methods to Page from an extension
Jacob Burkhart wrote:
> Loren Johnson wrote:
>>> class Page < ActiveRecord::Base
>>
>> Should be:
>>
>> YourPageClassName < Page
>
> No, I don't want to subclass page, I want to add methods to all pages.
>
> I could directly edit page.rb but I'd like to limit my edits to remain
> within the folder for my extension.
I am redefining page in the app/models directory of my extension
and in my extension definition I can explicitly load this verison of
page
like this:
load
"#{RADIANT_ROOT}/vendor/extensions/page_attributes/app/models/page.rb"
UGLY!
but that works...
Shouldn't it just get loaded by default. What do I do to fix this?
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Adding methods to Page from an extension
Loren Johnson wrote: >> class Page < ActiveRecord::Base > > Should be: > > YourPageClassName < Page No, I don't want to subclass page, I want to add methods to all pages. I could directly edit page.rb but I'd like to limit my edits to remain within the folder for my extension. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Adding methods to Page from an extension
Hey I feel like I'm missing something obvious, I created an extension that adds some columns to the pages table, and now I want to add some methods to the Page class. I put this at the bottom of my Extension class class Page < ActiveRecord::Base def test_new_method "hi" end end And now I'm getting errors like: undefined method `children' for # undefined method `parts' for # Which leads me to believe that my version of Page is being loaded, and the original version is not. How do I get them both to load? what's really going on here? Also, can somebody tell why "logger" is not defined from my Extension class How can I access the logger? thanks, Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Why do we have snippets, page-parts and layouts at all?
I don't follow all of your reasoning, But I would admit there is no need for Snippets. With the ability to easily handle different page types in Mental, "Snippet" could just be another page type. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Ordering of pages
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? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Ordering of pages
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... -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Ordering of pages
>> 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---
#
#
#
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
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@lists.radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Access to request object from within tags (answer?)
Storing the request at a class level is a very bad idea. At least I think it is... Isn't it possible that the same class could be used for multiple requests? It sounds to me like any solution would have to involve directly populating the request on the found pages within the tag definitions for r:find and r:children. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Ordering of pages
Ahh, attempting to implement 2 features at once? re-ordering as well as parent/hierarchy changing? While we're solving other problems at the same time, what about the problem of too many pages? The secondary screen we use for re-ordering, could also be the secondary screen we use to display the full list of pages under a particular parent when the number of children reaches a certain limit. (And we thus don't show all child pages in the full tree view). I'm a little worried, because I want my radiant users to be able to re-order things, but not to re-parent things. And having re-parenting through the same mechanism as re-ordering could make it more difficult to re-order, and could also make it a hassle to somehow permission things so that only re-ordering is allowed for certain user types... I think it's time for a mock-up... -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Reusable Page Parts - With A Twist
So, basically you're just looking for a bunch of debug output below the page part tabs about what's being used where? It's not really a functional change, just some information to help you setup your site the way you describe, right? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Ideas for reimplementation of radiant caching
Before changing how the caching works, I would ask, what are the reasons for modifying caching. I can think of a few. - It's annoying to have to clear page cache after every edit in order to view your change. The solution Dan suggests would make it possible to know exactly which pages need their cache cleared. However, having a "versioning" system like BJ suggests would also help to accomplish this goal. And even currently, you can have a dev URL to your site where none of the pages are cached. Also, I see no reason why we can't attach a Preview button directly to each page edit screen. - Apache is faster than Radiant's cache. Well then can we make Apache serve everything? Why not have the options to make Radiant generate a full directory of HTML files. A possible way to support having select pieces of the site be dynamic is to use Apache server side includes to make calls back to Radiant for specific pieces. Are there any other reasons for changing Radiant's caching? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] How to render template in behavior file?
John W. Long wrote: > Alexander Lomakin wrote: >> Of course this code will be executed with an error. Somebody knows >> alternative for " render :template => 'mytemplates/gootemplate' " >> code? It is possible? > > It's not presently possible. Why would you consider this behavior > desirable? It looks like he wants to use a Layout from a file instead of using one of the Layouts defined in the database. (via radiant admin) This would allow you yo use a text editor while your messing with a layout instead of working within the textarea radiant provides. It should be possible with a little bit of hackery... Am I right about what you are trying to do Alexander? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] What I actually meant to say was...
Oops, I accidentally hit return while editing the subject. Anyway this post has 2 purposes: 1. To explain what I want to do with Radiant, and to see if anybody else has ever tried. And to validate that my approach is correct. 2. To ask where/how it might most be useful to contribute what I plan on doing back into the core The details: I want to implement Page types. From an interface perspective, I'm imagining you'll see a little pop-up when you click "add child" in the pages admin asking you what type of page you want to make. I propose to implement each page type as a database table with a one to one relationship back to the pages table. We will assume that somehow we know about all tables that have this property and thus know that they are page types. I want to implement it so that anybody can create any arbitrary page type with very little work. (basically just create the database table) In my examples I will use the following example type: students name - short string grade - number birthday - date description - text page_id - (one to one relation back to pages) So for the purposes of this example you click "add child" in the pages admin you would be prompted to chose "standard page" or "student" Next, what do you see: If you chose "student" you would see an addional tab after your page parts called "Attributes" If you clicked this tab you would see a scaffolding-esque form for filling out all of the columns in the students table (you would then proceed to fill these out). In the body of your page (or in my case in the layout I select for my page) there will be additional r:tags for displaying the content-type specific attributes.for example. Once I have this working, I'd like "text" attributes to appear in seperate tabs with a WYSIWYG (remember they will not actually be page parts, they are still stored as attributes of the content type) I am also thinking about supporting file uploads in a similar manner. Once I have that working, I'd like to add a new user type (called content admin) who can only create and edit pages that are of a non-standard type. (all other actions in the admin would be greyed out) Finally, I'd like to support linking to other special page types via content types. So for instance: students name - short string grade - number birthday - date description - text page_id - (one to one relation back to pages) school_id - (foreign key to schools table) schools page_id - (one to one relation back to pages) etc... This way, when you create a student you can select which school they are in from a drop down showing all other school-typed pages. Remember, the idea here is not to add students and schools, but the ability for me to simply create those tables (and maybe their models) in a particular instance of radiant and have the core of the application recognize them as page types and allow me to manipulate then in the admin I want to be able to customize radiant with content types for a particular purpose and then hand it off to a more non-technical users. I eliminate the need for that user to know any radiant tags by creating a layout for each content item type (which would pull all of the relevant stuff from the attributes they populate) Any comments? Should I work from corex or mental? Does it sound like what I am trying to do might be broken by the currently planned roadmap for the next release of radiant? Can you explain to me how (If possible) I might develop the entirety of the functionality I just described as a "plug-in"? thanks, Jacob -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Where to contribute my ambitious change.
Hey Everybody, I have a -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
