Re: [Radiant] r:find question
On Dec 3, 2008, at 8:56 AM, Sean Cribbs wrote: YAY! Someone who agrees with me! The caveat, of course, is that often you need to put Radius tags inside the attributes of HTML tags. But that's because Radius is not strict XML, but interpolated. When explaining Radius to a local web design meetup, one sorta-technical guy suggested we use an XML parser/XSLT and I had to tell him no. It only looks like it could be. To add to this, another reason to avoid it is that it requires parsing the template twice. Once to parse the tags out and once to parse the attributes. I'm more interested in the idea of adding support for some kind of variable notation from within the tags. Something like Chris Parrish's extension, though I think the syntax could be improved. -- John Long http://wiseheartdesign.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] r:find question
Actually, I should probably clarify. I agree that IF you are going to use an XML paradigm, better to leave it be. That said as Radiant's been growing in popularity, I've been seeing more and more people hitting a wall here. I'm starting to wonder whether using an XML paradigm is really best. After all, I wouldn't think that the target Radiant user is necessarily familiar with XML. (And a href=r:slug// title=r:title//Link Text/a isn't all that elegant or XML consistent either -- as Sean noted). I realize that Radius' goal of maintaining simplicity is good -- I want elegance too -- but has anyone given any thought to these kinds of needs. My vote was with the desire for consistency, but that does still leave the legitimate, requested need un-addressed here. -Chris Chris Parrish wrote: +1 Sean Cribbs wrote: Adam van den Hoven wrote: EEEWWW NOO! Please don't do this. If you are going to use an XML paradigm for your DSL then stick to it. There is nothing that makes my skin crawl more than seeing tags as attribute values. Aside from pure aesthetics (which is considerable), there is the matter of tooling. I can find extensible WYSIWYG XML widgets (they're not as common or as cheap as I'd like) and none of them will never be able to handle this (IMHO, extending XML widgets may be better in the long term than wrapping textile or what have you). And and you'll never be able to debug it. I hate that we do this now for HTML attribute values, lets not pollute the paradigm more. Otherwise rolling something into HAML would be better (I'm guessing) YAY! Someone who agrees with me! The caveat, of course, is that often you need to put Radius tags inside the attributes of HTML tags. But that's because Radius is not strict XML, but interpolated. When explaining Radius to a local web design meetup, one sorta-technical guy suggested we use an XML parser/XSLT and I had to tell him no. It only looks like it could be. Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Freezing Gems?
Erik Ostrom said the following on 12/03/2008 02:35 AM: Hm. Since there isn't a clear standard for freezing gems, sometimes they need some coaxing. I'd try running it either (a) on a machine you have more control over or (b) on Mongrel, to try to get some more diagnostic logging. ... Okay, I've just tried freezing RedCloth 4.1.1 into my Radiant app at home. I got a Phusion error about a missing RubyGem echoe, installed and froze that, and now my app works. So if you didn't get echoe already, you could try that. Otherwise I don't know. Dreamhost is a hosted site, so the machine you have more control over isn't a fair test. I can't cotnrol the Passenger configuration and I'm stuck using the local GEM_HOME in ~/.gems I can't install gems in /usr/lib/ruby since this is a hosted service and when I point out that all I'm working with uses gems from the standard Ruby Gems repository Dreamhost support tell me its custom software and unsupported and when I point out that many of their gems are out of date they tell me they can't update until all the new ones have been tested. Apart from this incident Dreamhost have always been very supportive but this 'denial' and 'blame the user' is getting me very frustrated. -- It is impossible for a man to begin to learn what he thinks he knows. -- Epictetus ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] DB Indexes
I've applied Yevgeny's indexes (without the uniqueness constraints - YAGNI) and here's some circumstantial (i.e. not rigorous) results from running the spec suite: BEFORE Integration: 4.263972 Models: 51.04876 Controllers: 25.428781 Helpers: 1.062501 Lib: 2.166438 Generators:8.256952 --- real 137.84 user 58.80 sys 9.15 AFTER [speedup] Integration: 3.677267 (13.7%) Models: 38.548814 (24.5%) Controllers: 7.805954 (69.3%) Helpers: 0.987228 ( 7.1%) Lib: 1.283434 (40.7%) Generators:1.746686 (78.8%) --- real 87.59 user 60.00 sys 8.78 Now, you can throw out the differences on the Generators (they don't use the DB), Helpers, and probably Lib, but the changes on Integration, Models and Controllers are the most significant ones (and probably most accurate, since they take the longest). Plus, the overall 50 sec change in clock time to complete the specs was nice -- note that the user and sys didn't change much. Thanks, Yevgeny! Sean Yevgeny Smirnov wrote: I think, it's good to create the following DB indexes: add_index pages, [class_name] add_index pages, [parent_id] add_index pages, [slug, parent_id], :unique = true add_index pages, [virtual, status_id] add_index page_parts, [page_id, name], :unique = true Yevgeny Smirnov ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] DB Indexes
Sean Cribbs said the following on 12/03/2008 09:46 AM: I've applied Yevgeny's indexes (without the uniqueness constraints - YAGNI) and here's some circumstantial (i.e. not rigorous) results from running the spec suite: BEFORE ... --- real 137.84 user 58.80 sys 9.15 AFTER [speedup] ... --- real 87.59 user 60.00 sys 8.78 [...] -- note that the user and sys didn't change much. Thanks, Yevgeny! I've applied the indexes to a number of hosted sites and the user response is that they feel a lot more snappier. I suspect some of the extensions would benefit from indexes on the fields they add, but that's another and more specialized matter. I also suspect that matters such as the database type used (Sqlite, MySQL, ...), the type of table (MyISAM, InnoDB ... see http://www.unixcities.com/mysql/manual_table_types.html) will also affect the efficacy of indexes. As with so many things in the modern world, there are going to be a lot of ifs and but and and as I keep saying ... Context is Everything But yes, these are, in retrospect, so obvious. Can we merge them into the core? -- Sometimes I lie awake at night, and I ask, Where have I gone wrong? Then a voice says to me, This is going to take more than one night. Charles M. Schulz, Charlie Brown in Peanuts ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] DB Indexes
But yes, these are, in retrospect, so obvious. Can we merge them into the core? http://is.gd/a2J9 Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] r:find question
I don't think that the issue at hand is the average user who is going
to be hacking with the source code. They don't exist. You start
hacking with source code and you need to be at a higher level of
expertise.
JSTL and JSP EL handle this more elegantly (how much more is a matter
of taste) where you can do (I'll freely mix radius and jstl for effect):
c:set var=myVarr:slug //c:set
a:href=${myVar}r:title //a
I'm in the process of turning all of HTML into a JSP TagLib (honest)
so that I can do (again mixing with radius):
a title=here is my title attribute
jspx:attribute name=hrefr:slug //jspx:attribute
r:title /
/a
which will produce exactly what you expect.
It may be verbose, but I actually like the later approach better and I
think that something like his might be valuable for radius?
On 3-Dec-08, at 6:29 AM, Chris Parrish wrote:
Actually, I should probably clarify. I agree that IF you are going
to use an XML paradigm, better to leave it be. That said as
Radiant's been growing in popularity, I've been seeing more and more
people hitting a wall here.
I'm starting to wonder whether using an XML paradigm is really
best. After all, I wouldn't think that the target Radiant user is
necessarily familiar with XML. (And a href=r:slug//
title=r:title//Link Text/a isn't all that elegant or XML
consistent either -- as Sean noted).
I realize that Radius' goal of maintaining simplicity is good -- I
want elegance too -- but has anyone given any thought to these kinds
of needs. My vote was with the desire for consistency, but that
does still leave the legitimate, requested need un-addressed here.
-Chris
Chris Parrish wrote:
+1
Sean Cribbs wrote:
Adam van den Hoven wrote:
EEEWWW NOO!
Please don't do this. If you are going to use an XML paradigm for
your DSL then stick to it. There is nothing that makes my skin
crawl more than seeing tags as attribute values.
Aside from pure aesthetics (which is considerable), there is the
matter of tooling. I can find extensible WYSIWYG XML widgets
(they're not as common or as cheap as I'd like) and none of them
will never be able to handle this (IMHO, extending XML widgets
may be better in the long term than wrapping textile or what have
you). And and you'll never be able to debug it.
I hate that we do this now for HTML attribute values, lets not
pollute the paradigm more. Otherwise rolling something into HAML
would be better (I'm guessing)
YAY! Someone who agrees with me!
The caveat, of course, is that often you need to put Radius tags
inside the attributes of HTML tags. But that's because Radius is
not strict XML, but interpolated. When explaining Radius to a
local web design meetup, one sorta-technical guy suggested we use
an XML parser/XSLT and I had to tell him no. It only looks like
it could be.
Sean
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Templates extension documentation?
Is there a tutorial or some sort of example of how the templates extension works in practice? There is some info in the readme but there aren't any examples of how it works. It looks like a way to create a page that is simply a collection of snippets. What I thought it was is a way to have nested partials, but that doesn't seem to be the case. ~Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] plugin jrails prevents adding page parts
If you are just using jQuery (presumably for your production site not the admin interface) why not save yourself the hassle and use the copy in Google's CDN? http://code.google.com/apis/ajaxlibs/ You can do things using Google's loader (which I'm not a huge fan of, though it is a neat idea) or you can simply use their URI: http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js . Save yourself the maintenance. On 3-Dec-08, at 2:44 PM, bruce davison wrote: Jim, Yes I am sure you are right I realised I don't need jrails, since I am not using it. I just needed jQuery, which I now have in public/ javascripts and works just fine. Thanks, Bruce Jim Gay wrote: On Dec 2, 2008, at 8:02 PM, bruce davison wrote: I need to use jQuery and added the plugin jrails. The code for jquery works find when I include the js in the layout, but when I try to add page parts only part of the page is showing no button to create etc. When I removed jrails from the plugins 'add page part' works again. Radiant isn't using RJS for adding page parts in 0.6.9, so it's likely that jrails is screwing up the $ function. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
