I just noticed a facets branch in svn.
What’s the goal of this branch?
Jacob B. wrote:
I just noticed a facets branch in svn.
What’s the goal of this branch?
This is a branch that I initiated this week based on some of Daniel
Sheppard’s initial compartmentalization of the page editing interface.
I took it to the next level, and now the page editing interface is
pretty flexible for extension and modification. There’s a sample
extension included that modifies the interface to provide a page preview
functionality.
Sean
This is a branch that I initiated this week based on some of Daniel
Sheppard’s initial compartmentalization of the page editing interface.
I took it to the next level, and now the page editing interface is
pretty flexible for extension and modification. There’s a sample
extension included that modifies the interface to provide a page preview
functionality.
When are you planning to merge back the changes to mental?
–
Alexander H.
http://www2.truman.edu/~ah428
I’d like people to use it and work with it first. Could you give it a
whirl this weekend? I also considered expanding its reach to the snippets
and layout editing interfaces.
Sure. As the first step in testing your changes, what is the expected
behavior supposed to be? Could you describe the objectives and what
needs to be tested in particular?
On 2/10/07, Sean C. [email protected] wrote:
Sheppard’s initial compartmentalization of the page editing interface.
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site:
http://lists.radiantcms.org/mailman/listinfo/radiant
–
Alexander H.
http://www2.truman.edu/~ah428
I’d like people to use it and work with it first. Could you give it a
whirl this weekend? I also considered expanding its reach to the
snippets and layout editing interfaces.
Sean
The unit tests work without fail; instead I’d like feedback on the
interface/API.
The editing interface is broken into multiple partials. Three of these
partials are top-level – edit_form, edit_popups, and
edit_scripts_and_styles. They each also define ‘regions’ using the <%=
render_region :some_region %>. Inside these regions are rendered
partials that fill out the interface, and also define their own regions,
if necessary. So essentially, I can insert my own partials at many
points in the interface. An example is shown in the sample extension
that is included.
So, basically, if I want to add a top-level partial (i.e. not rendered
inside a region), I would do one of these commands in the activate
method of my extension:
admin.page.edit_partials << “my_partial”
admin.page.edit_partials.add “my_other_partial”
admin.page.edit_partials.add “yet_another_partial”, :before =>
“my_other_partial”
The before/after works just like when adding tabs. The default behavior
of that is to tack the new partials on the end, unless otherwise
specified. You can also add partials to specific regions:
admin.page.edit_partials.add “regional_partial”, :region => :form,
:before => “edit_layout_and_type”
Again, the before/after works for regions as well. The currently
available regions are:
:scripts (javascripts)
:styles (css)
:popups
:form (inside the brown form area)
:form_top (above the brown form area)
:form_bottom (below the brown form area)
:extended_metadata (inside the slug/breadcrumb table)
:part_controls (inside the filter/reference row on each tab)
:layout_row (next to layout/type/status)
:buttons (in the row with the submit buttons and cancel link)
If you want a preview of what is in each region and in what order, look
at lib/radiant/initializer.rb – the same place where tabs are
initialized.
In addition to the regions defined for them, you can add additional
Javascripts or CSS in any partial with an ERb block:
<% additional_page_styles do %>
.blue-row { background-color: navy; }
<% end %>
<% additional_page_scripts do %>
// some javascript code
<% end %>
These will be rendered inside the section of the page like the
other scripts and styles.
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.
Sean
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…
Hi Jason
On 12/02/07, Jacob B. [email protected] wrote:
If only I could view
source of the TabControl generated DOM…
Havent had chance to look at this branch yet but sounds interesting.
Anyway…
On this question you probably can. Both the Web D. Tool Bar [1]
and Firebug [2] extensions to Firefox allow you to view the live DOM,
after Javascript effects. Use View Source > View Generated Source in
Web Dev Tool bar.
[1] https://addons.mozilla.org/firefox/60/
[2] https://addons.mozilla.org/firefox/1843/
Hope that’s useful.
Gareth
–
Posted via http://www.ruby-forum.com/.
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
–
Gareth Rushgrove
morethanseven.net
webdesignbookshelf.com
refreshnewcastle.org