Re: [Radiant] Reorder Extension testing issues
On Fri, Mar 19, 2010 at 3:38 PM, Jim Gay wrote: > Don't try to fix it. If a core spec is defined to expect things in a > default order but an extension changes the default, then those added specs > will fail. The only way around this would be to undefine the original specs, > but I'm not sure of a way to do that. > I'll add a +1 to Jim on that. The right way to handle this would be for the new find method to test and and see if an order clause was passed in, and use that clause if it was, while defaulting to position order if no other order is specified. (If the core spec insists on another default order, *then* it's time to address the idea of changing the core spec, as that approach is almost guaranteed to cause issues with extensions.) I've had lots of issues with interactions between both drag_order and reorder and r:children tags because of that. (For some items, I want descending order by date, for others I want a specific page order.) I'd planned on forking reorder to do that (I'm migrating a wordpress site with 150+ posts, and I'm sick of reordering them as I migrate them; the current state of reorder lets the "asc" and "desc" values through, but overrides the date_published order with position order) once I got the tests to run sensibly. I'm having trouble with that at the moment, though. Which means that the column doesn't exist. So it sounds to me like Anna is > merely seeing the result of the altered behavior with a position column, but > Arlen doesn't even have the position column. > Yep. I can run the migration and look at the test db and see the position column, but when I run the tests, the test db gets rebuilt *without* the position column, which I've verified. I'm still sure I'm overthinking this, and when I find out what's wrong I'm going to feel stupid, but so far I'm still mystified. Gonna put it down for a while and come back to it with fresh eyes. I haven't had a chance to really look into this, but I have seen the problem > before and can't recall how it was fixed for me (other than running "rake > RAILS_ENV=test db:migrate:extensions") That actually worked in one installation here, the 0.8.1 one. But it just stares at me blankly in the edge one. I'm sure I've screwed something up, and it's something simple. It just feels like it. (I'm liking the edge code better than 0.8.1 at the moment, so I'll probably be using it for the migration.) ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
Re: [Radiant] Reorder Extension testing issues
Jim, yeah that's what I responded to Arlen initially, that it looked like his test environment hadn't been migrated with the extension in mind. I was on site on a project where running tests from Radiant root was discouraged, so we ended up isolating our tests. I'm not sure what we did to resolve it. Arlen- here is some backstory on testing and edge, btw http://groups.google.com/group/radiantcms-dev/browse_thread/thread/a7c55cacecb99168/f66689a4cfe81b4d?lnk=gst&q=gem++edge#f66689a4cfe81b4d ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
Re: [Radiant] Reorder Extension testing issues
On Mar 19, 2010, at 4:29 PM, banane wrote: > I was really hoping someone else would chime in on this... > > I loaded up drag_reorder, a fork of bright4's that I did a while ago, > and sure enough get a gazillion test errors when I migrate. So, I'm > thinking, by looking at one of the errors, that it has to do with the > extension of a model's find method. So if tests use that, the > condition is different now- no longer by published_at date, but now by > position. I'm not sure why that's an issue, or how to fix it. feeling Don't try to fix it. If a core spec is defined to expect things in a default order but an extension changes the default, then those added specs will fail. The only way around this would be to undefine the original specs, but I'm not sure of a way to do that. The original post, however, listed this as the problem: "Mysql::Error: Unknown column 'position' in 'order clause':" Which means that the column doesn't exist. So it sounds to me like Anna is merely seeing the result of the altered behavior with a position column, but Arlen doesn't even have the position column. I haven't had a chance to really look into this, but I have seen the problem before and can't recall how it was fixed for me (other than running "rake RAILS_ENV=test db:migrate:extensions") -Jim > kind of overwhelmed with the wordpress-migrator thing, otherwise I'd > jump in. anyone else have a workaround for this? > > On Thu, Mar 18, 2010 at 8:40 PM, Arlen Walker wrote: >> >> On Mar 18, 2010, at 7:55 PM, banane wrote: >> >>> This reminds me I should really go back to TDD (ducks). Ha, these >>> errors you're having are familiar, but I can't remember the silver >>> bullet- if there was any-that solved it. Part of me wants to say, the >>> extension developers wrote their tests with one gem version, whereas >>> radiant wrote theirs with another, hence the discrepancy you're >>> seeing. >> >> This has been my biggest frustration. It's very much like the Windows "DLL >> Hell" phenomenon. I'm really going to have to dig in to why a new version of >> RSpec (fer cryin out loud) gets in the way of a db migration!! I just get >> the feeling that if I tweak one little thing, the whole house is going to >> come down, something I thought testing was supposed to help us get away from. >> >> Anyway, enough with the venting. I'm in the process of creating some >> extensions (one of the reasons for doing this was to figure out how to get >> started at that -- I've done a little of it but it's more "cargo cult" stuff >> than real development and I wanted to take apart a working extension to see >> how it ticks). The real question is how to go about setting up a development >> environment that I can use for this. >> >> Right now my impression is that edge is better than 0.8.1, so I'm probably >> going to start moving in that direction, hoping to land on 0.9 when it's >> ready. But I keep running into dependencies on really old testing gems. >> >> ah, well. off to bed. >> >> Have Fun, >> Arlen >> >> -- >> In God we trust, all others must supply data ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
Re: [Radiant] Reorder Extension testing issues
I was really hoping someone else would chime in on this... I loaded up drag_reorder, a fork of bright4's that I did a while ago, and sure enough get a gazillion test errors when I migrate. So, I'm thinking, by looking at one of the errors, that it has to do with the extension of a model's find method. So if tests use that, the condition is different now- no longer by published_at date, but now by position. I'm not sure why that's an issue, or how to fix it. feeling kind of overwhelmed with the wordpress-migrator thing, otherwise I'd jump in. anyone else have a workaround for this? On Thu, Mar 18, 2010 at 8:40 PM, Arlen Walker wrote: > > On Mar 18, 2010, at 7:55 PM, banane wrote: > >> This reminds me I should really go back to TDD (ducks). Ha, these >> errors you're having are familiar, but I can't remember the silver >> bullet- if there was any-that solved it. Part of me wants to say, the >> extension developers wrote their tests with one gem version, whereas >> radiant wrote theirs with another, hence the discrepancy you're >> seeing. > > This has been my biggest frustration. It's very much like the Windows "DLL > Hell" phenomenon. I'm really going to have to dig in to why a new version of > RSpec (fer cryin out loud) gets in the way of a db migration!! I just get the > feeling that if I tweak one little thing, the whole house is going to come > down, something I thought testing was supposed to help us get away from. > > Anyway, enough with the venting. I'm in the process of creating some > extensions (one of the reasons for doing this was to figure out how to get > started at that -- I've done a little of it but it's more "cargo cult" stuff > than real development and I wanted to take apart a working extension to see > how it ticks). The real question is how to go about setting up a development > environment that I can use for this. > > Right now my impression is that edge is better than 0.8.1, so I'm probably > going to start moving in that direction, hoping to land on 0.9 when it's > ready. But I keep running into dependencies on really old testing gems. > > ah, well. off to bed. > > Have Fun, > Arlen > > -- > In God we trust, all others must supply data > > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > List Site: http://lists.radiantcms.org/mailman/listinfo/radiant > Radiant: http://radiantcms.org > Extensions: http://ext.radiantcms.org > ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
Re: [Radiant] Radiant] Layout Source Control (etc)
Jim - This is excellent, thanks for sharing! The timing of this thread couldn't be more perfect for me. Everyone/Josh - this fs extension pretty much does exactly what you need it to. So far so awesome! - J On Fri, Mar 19, 2010 at 1:42 PM, Jim Gay wrote: > On Mar 19, 2010, at 1:13 PM, Josh French wrote: > > >> Question is, what is the best way of doing this - there seems to be > >> a few > >> extensions out there for copying layouts in and out of the database, > >> but > >> nothing that seems to make a file based layout a first class > >> citizen... > > > > We've been using the File System extension ( > http://ext.radiantcms.org/extensions/67-file-system > > ) but I recently looked into File System Resources ( > http://ext.radiantcms.org/extensions/148-file-system-resources > > ) and I think I like its approach better. > > I agree. File System Resources is a bit better since you don't need to copy > data back and forth. > I have a few updates in my fork > http://github.com/saturnflyer/radiant-file-system-resources-extension > > But if the original question is about the files being first class citizens, > you still need to connect it to the data in the database somehow. > Without copying (like File System) or registering (like File System > Resources) you'd either need to alter the code to just look for your layout > file (only one, or select based on URL, or something) or you'd need to alter > the pages table to select a layout_file instead of a layout_id. > If each page had a layout_file, you could do away with the Layouts tab > altogether or change it to only show what you have in the file system. > Snippets would be even easier since there are no references to that table > (but I'd choose a different name for that, like Fragments or something, just > to keep your head clear). > > Jim Gay > http://www.saturnflyer.com > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > List Site: http://lists.radiantcms.org/mailman/listinfo/radiant > Radiant: http://radiantcms.org > Extensions: http://ext.radiantcms.org > ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
Re: [Radiant] Radiant] Layout Source Control (etc)
On Mar 19, 2010, at 1:13 PM, Josh French wrote: >> Question is, what is the best way of doing this - there seems to be >> a few >> extensions out there for copying layouts in and out of the database, >> but >> nothing that seems to make a file based layout a first class >> citizen... > > We've been using the File System extension > (http://ext.radiantcms.org/extensions/67-file-system > ) but I recently looked into File System Resources > (http://ext.radiantcms.org/extensions/148-file-system-resources > ) and I think I like its approach better. I agree. File System Resources is a bit better since you don't need to copy data back and forth. I have a few updates in my fork http://github.com/saturnflyer/radiant-file-system-resources-extension But if the original question is about the files being first class citizens, you still need to connect it to the data in the database somehow. Without copying (like File System) or registering (like File System Resources) you'd either need to alter the code to just look for your layout file (only one, or select based on URL, or something) or you'd need to alter the pages table to select a layout_file instead of a layout_id. If each page had a layout_file, you could do away with the Layouts tab altogether or change it to only show what you have in the file system. Snippets would be even easier since there are no references to that table (but I'd choose a different name for that, like Fragments or something, just to keep your head clear). Jim Gay http://www.saturnflyer.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
Re: [Radiant] Radiant] Layout Source Control (etc)
> Question is, what is the best way of doing this - there seems to be > a few > extensions out there for copying layouts in and out of the database, > but > nothing that seems to make a file based layout a first class > citizen... We've been using the File System extension (http://ext.radiantcms.org/extensions/67-file-system ) but I recently looked into File System Resources (http://ext.radiantcms.org/extensions/148-file-system-resources ) and I think I like its approach better. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
[Radiant] Layout Source Control (etc)
I realise this has been covered a little over the past year or two, but I have one specific use case I need to figure out. Essentially, we are developing sites, but we would like to keep the code for the site in Git (for history, and also to make deployments nice and easy). Thing is, we would like to include layouts (and sometimes snippets) in that control, as layouts aren't something that we like the client to mess with, their job is content. Question is, what is the best way of doing this - there seems to be a few extensions out there for copying layouts in and out of the database, but nothing that seems to make a file based layout a first class citizen... -- Neil Middleton Technical Lead Monochrome Ltd ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ List Site: http://lists.radiantcms.org/mailman/listinfo/radiant Radiant: http://radiantcms.org Extensions: http://ext.radiantcms.org
