You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(72) |
Oct
(15) |
Nov
(68) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nathan D. <na...@ch...> - 2003-01-21 06:00:47
|
All you really need is the org -- but, the sampleapps are handy too. - Nathan ---------------------------- Nathan Dintenfass na...@ch... 415.793.9304 http://nathan.dintenfass.com Now bloggin' at: http://www.changemedia.org > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Brad Pauly > Sent: Monday, January 20, 2003 3:37 PM > To: modus devs > Subject: [Modus-devs] cvs modules > > > Hi All, > > I was hoping to try out the latest modus code. Which modules do I need > to grab from cvs? org and sampleapps?? > > Thanks, > Brad > > ps - sorry if this posts twice, I had some trouble. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > |
From: Brad P. <br...@ro...> - 2003-01-20 23:40:52
|
Hi All, I was hoping to try out the latest modus code. Which modules do I need to grab from cvs? org and sampleapps?? Thanks, Brad ps - sorry if this posts twice, I had some trouble. |
From: Jeremy F. <jfi...@ma...> - 2003-01-09 01:56:35
|
> I should really spend more time getting to know your whole code base before > asking my "dumb questions" -- but that one has me confused. The first attempt at CVS-ing I wound up hosing a whole bunch of the code, which I've just fixed - thanks to the backups on my fancy new USB flash drive. Sorry Nathan, download the new org and sampleapp directories (or just cvs update them) and things should work. -J > > -----Original Message----- > > From: mod...@li... > > [mailto:mod...@li...]On Behalf Of Jeremy > > Firsenbaum > > Sent: Wednesday, January 08, 2003 4:21 PM > > To: mod...@li... > > Subject: Re: [Modus-devs] New Code Base > > > > > > > I could not find the actual 'content objects' in the CVS stuff I > > grabbed -- > > > like, sampleapps.pressrelease.contenttypes.pressrelease > > > > They're in the org.bacfug.sampleapps directory. I was trying to > > promote the > > use of a standard place for cfc's - these could even be outside > > the web root > > if remoting or web services are not required. > > > > > > > > > > > -----Original Message----- > > > > From: mod...@li... > > > > [mailto:mod...@li...]On Behalf Of Jeremy > > > > Firsenbaum > > > > Sent: Wednesday, January 08, 2003 9:01 AM > > > > To: modus devs > > > > Subject: [Modus-devs] New Code Base > > > > > > > > > > > > Well there it is. Sorry I've been sitting on this so long, but > > > > after things > > > > slowed down in November I've continued to work without the regular > > updates > > > > to the list. I think we've got a fairly stable code base now. > > > > There's plenty > > > > to pick apart and I hope y'all find lots to refine. > > > > > > > > It's been so long I don't really remember where we left off, but > > > > I've spent > > > > most of my time working on the persister component. Collections, my > > > > pipedream a few months back, are now fully implemented with many2one, > > > > one2many and many2many relationship support. See modus/docs/Modus User > > and > > > > Developer Guide.rtf for details. > > > > > > > > Also the API facade component, which I've called a library > > for want of a > > > > better term, is nice and clean now. No more application scope > > > > anywhere - all > > > > calls go through server.modus. > > > > > > > > There's a new sampleapps directory that contains Nathan's simple > > > > pressrelease as well the forums hack of an app I was using for > > > > proof-of-concept. Some of the automagical database stuff > > still needs to > > be > > > > worked out so you'll have to install the SQL Server db file to see the > > > > forums in action. > > > > > > > > There are two outstanding issues I need to work on: fields are > > > > global right > > > > now, which means the component is not tied to a content type > > field. The > > > > validator would be much cleaner if each field had its own > > > > component so that > > > > the rules could be handled internally, rather than in the > > > > validator itself. > > > > Also, I want to get the table creation code working so that users > > > > don't need > > > > to touch a database, but will wait to see what everyone thinks of the > > > > dbpersister implementation. There was a built-in stored procedure for > > > > SQLServer that I've exploited to get field types (see > > > > persistence/dmmssql.cfc), which is why I haven't gotten any other db's > > > > working yet. > > > > > > > > When everyone on this list is ready, we can wrap all of this up into a > > v3 > > > > release for the Sourceforge site and update the project page to > > > > reflect this > > > > new outlook. > > > > > > > > Again, don't let anything get in the way of honest criticism. The > > > > idea is to > > > > make this as useful and useable as possible, so I look > > forward to all of > > > > your feedback. > > > > > > > > -Jeremy > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.NET email is sponsored by: > > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > > http://www.vasoftware.com > > > > _______________________________________________ > > > > Modus-devs mailing list > > > > Mod...@li... > > > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > http://www.vasoftware.com > > > _______________________________________________ > > > Modus-devs mailing list > > > Mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs |
From: Nathan D. <na...@ch...> - 2003-01-09 01:00:09
|
Ah, OK, I just got the org/bacfug/modus instead of the whole "org" tree the first time. So, then does sampleapps.pressrelease.contenttypes.pressrelease refer to the component that is actually in org.bacfug.sampleapps.pressrelease.pressrelease ?? Are the paths to content objects inside of applications not "real" paths to content objects? I should really spend more time getting to know your whole code base before asking my "dumb questions" -- but that one has me confused. - Nathan > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Jeremy > Firsenbaum > Sent: Wednesday, January 08, 2003 4:21 PM > To: mod...@li... > Subject: Re: [Modus-devs] New Code Base > > > > I could not find the actual 'content objects' in the CVS stuff I > grabbed -- > > like, sampleapps.pressrelease.contenttypes.pressrelease > > They're in the org.bacfug.sampleapps directory. I was trying to > promote the > use of a standard place for cfc's - these could even be outside > the web root > if remoting or web services are not required. > > > > > > > -----Original Message----- > > > From: mod...@li... > > > [mailto:mod...@li...]On Behalf Of Jeremy > > > Firsenbaum > > > Sent: Wednesday, January 08, 2003 9:01 AM > > > To: modus devs > > > Subject: [Modus-devs] New Code Base > > > > > > > > > Well there it is. Sorry I've been sitting on this so long, but > > > after things > > > slowed down in November I've continued to work without the regular > updates > > > to the list. I think we've got a fairly stable code base now. > > > There's plenty > > > to pick apart and I hope y'all find lots to refine. > > > > > > It's been so long I don't really remember where we left off, but > > > I've spent > > > most of my time working on the persister component. Collections, my > > > pipedream a few months back, are now fully implemented with many2one, > > > one2many and many2many relationship support. See modus/docs/Modus User > and > > > Developer Guide.rtf for details. > > > > > > Also the API facade component, which I've called a library > for want of a > > > better term, is nice and clean now. No more application scope > > > anywhere - all > > > calls go through server.modus. > > > > > > There's a new sampleapps directory that contains Nathan's simple > > > pressrelease as well the forums hack of an app I was using for > > > proof-of-concept. Some of the automagical database stuff > still needs to > be > > > worked out so you'll have to install the SQL Server db file to see the > > > forums in action. > > > > > > There are two outstanding issues I need to work on: fields are > > > global right > > > now, which means the component is not tied to a content type > field. The > > > validator would be much cleaner if each field had its own > > > component so that > > > the rules could be handled internally, rather than in the > > > validator itself. > > > Also, I want to get the table creation code working so that users > > > don't need > > > to touch a database, but will wait to see what everyone thinks of the > > > dbpersister implementation. There was a built-in stored procedure for > > > SQLServer that I've exploited to get field types (see > > > persistence/dmmssql.cfc), which is why I haven't gotten any other db's > > > working yet. > > > > > > When everyone on this list is ready, we can wrap all of this up into a > v3 > > > release for the Sourceforge site and update the project page to > > > reflect this > > > new outlook. > > > > > > Again, don't let anything get in the way of honest criticism. The > > > idea is to > > > make this as useful and useable as possible, so I look > forward to all of > > > your feedback. > > > > > > -Jeremy > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.NET email is sponsored by: > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > http://www.vasoftware.com > > > _______________________________________________ > > > Modus-devs mailing list > > > Mod...@li... > > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > |
From: Jeremy F. <jfi...@ma...> - 2003-01-09 00:21:21
|
> I could not find the actual 'content objects' in the CVS stuff I grabbed -- > like, sampleapps.pressrelease.contenttypes.pressrelease They're in the org.bacfug.sampleapps directory. I was trying to promote the use of a standard place for cfc's - these could even be outside the web root if remoting or web services are not required. > > > -----Original Message----- > > From: mod...@li... > > [mailto:mod...@li...]On Behalf Of Jeremy > > Firsenbaum > > Sent: Wednesday, January 08, 2003 9:01 AM > > To: modus devs > > Subject: [Modus-devs] New Code Base > > > > > > Well there it is. Sorry I've been sitting on this so long, but > > after things > > slowed down in November I've continued to work without the regular updates > > to the list. I think we've got a fairly stable code base now. > > There's plenty > > to pick apart and I hope y'all find lots to refine. > > > > It's been so long I don't really remember where we left off, but > > I've spent > > most of my time working on the persister component. Collections, my > > pipedream a few months back, are now fully implemented with many2one, > > one2many and many2many relationship support. See modus/docs/Modus User and > > Developer Guide.rtf for details. > > > > Also the API facade component, which I've called a library for want of a > > better term, is nice and clean now. No more application scope > > anywhere - all > > calls go through server.modus. > > > > There's a new sampleapps directory that contains Nathan's simple > > pressrelease as well the forums hack of an app I was using for > > proof-of-concept. Some of the automagical database stuff still needs to be > > worked out so you'll have to install the SQL Server db file to see the > > forums in action. > > > > There are two outstanding issues I need to work on: fields are > > global right > > now, which means the component is not tied to a content type field. The > > validator would be much cleaner if each field had its own > > component so that > > the rules could be handled internally, rather than in the > > validator itself. > > Also, I want to get the table creation code working so that users > > don't need > > to touch a database, but will wait to see what everyone thinks of the > > dbpersister implementation. There was a built-in stored procedure for > > SQLServer that I've exploited to get field types (see > > persistence/dmmssql.cfc), which is why I haven't gotten any other db's > > working yet. > > > > When everyone on this list is ready, we can wrap all of this up into a v3 > > release for the Sourceforge site and update the project page to > > reflect this > > new outlook. > > > > Again, don't let anything get in the way of honest criticism. The > > idea is to > > make this as useful and useable as possible, so I look forward to all of > > your feedback. > > > > -Jeremy > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > Modus-devs mailing list > > Mod...@li... > > https://lists.sourceforge.net/lists/listinfo/modus-devs > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs |
From: Nathan D. <na...@ch...> - 2003-01-08 23:50:00
|
Jeremy: Glad to see what you've been working on! I could not find the actual 'content objects' in the CVS stuff I grabbed -- like, sampleapps.pressrelease.contenttypes.pressrelease ?? > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Jeremy > Firsenbaum > Sent: Wednesday, January 08, 2003 9:01 AM > To: modus devs > Subject: [Modus-devs] New Code Base > > > Well there it is. Sorry I've been sitting on this so long, but > after things > slowed down in November I've continued to work without the regular updates > to the list. I think we've got a fairly stable code base now. > There's plenty > to pick apart and I hope y'all find lots to refine. > > It's been so long I don't really remember where we left off, but > I've spent > most of my time working on the persister component. Collections, my > pipedream a few months back, are now fully implemented with many2one, > one2many and many2many relationship support. See modus/docs/Modus User and > Developer Guide.rtf for details. > > Also the API facade component, which I've called a library for want of a > better term, is nice and clean now. No more application scope > anywhere - all > calls go through server.modus. > > There's a new sampleapps directory that contains Nathan's simple > pressrelease as well the forums hack of an app I was using for > proof-of-concept. Some of the automagical database stuff still needs to be > worked out so you'll have to install the SQL Server db file to see the > forums in action. > > There are two outstanding issues I need to work on: fields are > global right > now, which means the component is not tied to a content type field. The > validator would be much cleaner if each field had its own > component so that > the rules could be handled internally, rather than in the > validator itself. > Also, I want to get the table creation code working so that users > don't need > to touch a database, but will wait to see what everyone thinks of the > dbpersister implementation. There was a built-in stored procedure for > SQLServer that I've exploited to get field types (see > persistence/dmmssql.cfc), which is why I haven't gotten any other db's > working yet. > > When everyone on this list is ready, we can wrap all of this up into a v3 > release for the Sourceforge site and update the project page to > reflect this > new outlook. > > Again, don't let anything get in the way of honest criticism. The > idea is to > make this as useful and useable as possible, so I look forward to all of > your feedback. > > -Jeremy > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Modus-devs mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/modus-devs > |
From: Jeremy F. <jfi...@ma...> - 2003-01-08 17:01:54
|
Well there it is. Sorry I've been sitting on this so long, but after things slowed down in November I've continued to work without the regular updates to the list. I think we've got a fairly stable code base now. There's plenty to pick apart and I hope y'all find lots to refine. It's been so long I don't really remember where we left off, but I've spent most of my time working on the persister component. Collections, my pipedream a few months back, are now fully implemented with many2one, one2many and many2many relationship support. See modus/docs/Modus User and Developer Guide.rtf for details. Also the API facade component, which I've called a library for want of a better term, is nice and clean now. No more application scope anywhere - all calls go through server.modus. There's a new sampleapps directory that contains Nathan's simple pressrelease as well the forums hack of an app I was using for proof-of-concept. Some of the automagical database stuff still needs to be worked out so you'll have to install the SQL Server db file to see the forums in action. There are two outstanding issues I need to work on: fields are global right now, which means the component is not tied to a content type field. The validator would be much cleaner if each field had its own component so that the rules could be handled internally, rather than in the validator itself. Also, I want to get the table creation code working so that users don't need to touch a database, but will wait to see what everyone thinks of the dbpersister implementation. There was a built-in stored procedure for SQLServer that I've exploited to get field types (see persistence/dmmssql.cfc), which is why I haven't gotten any other db's working yet. When everyone on this list is ready, we can wrap all of this up into a v3 release for the Sourceforge site and update the project page to reflect this new outlook. Again, don't let anything get in the way of honest criticism. The idea is to make this as useful and useable as possible, so I look forward to all of your feedback. -Jeremy |
From: Robby L. <dig...@ho...> - 2003-01-05 12:59:02
|
Thanks Nathan, I appreciate the response..I'm in all honesty not heavy engaged in cfcs as of yet, honestly I'm still trying to grasp some of the concepts. Which will slow some of my "ability to help". But I still think the project is worth the grasp, and I'll catch up with the older list posts, . as soon as I can get Sourcforge to allow me to do so, .. for some reason it keeps fighting me saying I can't view them... just one of those days, .. Robby >From: "Nathan Dintenfass" <na...@ch...> >Reply-To: mod...@li... >To: <mod...@li...> >Subject: RE: [Modus-devs] Happy New Year.. and hello.. >Date: Wed, 1 Jan 2003 10:58:32 -0800 > >Robby: > >Welcome. Modus has progressed slowly of late. You may want to check out >the archives for this list at SourceForge to get a sense of some of the >issues we were discussing a couple months ago. > >Jeremy Firsenbaum has been doing some work to restructure Modus -- your >presence may be a catalyst to get things started back up. > > - Nathan > > > -----Original Message----- > > From: mod...@li... > > [mailto:mod...@li...]On Behalf Of Robby L. > > Sent: Tuesday, December 31, 2002 10:51 AM > > To: mod...@li... > > Subject: [Modus-devs] Happy New Year.. and hello.. > > > > > > Ex-php'er turned Diehard Cold Fusion Freak.. > > > > I'm not quite sure on the conversation level within this mailing > > list. But I > > would just like to say hello. And I think its a great idea and > > I'd like to > > be apart of (as much as my limited knowledge allows). "I'm" currently > > working on a couple of side projects of my own, xml and cfcs for the >most > > part, But if there is anything I can do, or throw my two cents > > on, just let > > me know. > > > > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Modus-devs mailing list >Mod...@li... >https://lists.sourceforge.net/lists/listinfo/modus-devs _________________________________________________________________ Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail |
From: Nathan D. <na...@ch...> - 2003-01-01 18:54:48
|
Robby: Welcome. Modus has progressed slowly of late. You may want to check out the archives for this list at SourceForge to get a sense of some of the issues we were discussing a couple months ago. Jeremy Firsenbaum has been doing some work to restructure Modus -- your presence may be a catalyst to get things started back up. - Nathan > -----Original Message----- > From: mod...@li... > [mailto:mod...@li...]On Behalf Of Robby L. > Sent: Tuesday, December 31, 2002 10:51 AM > To: mod...@li... > Subject: [Modus-devs] Happy New Year.. and hello.. > > > Ex-php'er turned Diehard Cold Fusion Freak.. > > I'm not quite sure on the conversation level within this mailing > list. But I > would just like to say hello. And I think its a great idea and > I'd like to > be apart of (as much as my limited knowledge allows). "I'm" currently > working on a couple of side projects of my own, xml and cfcs for the most > part, But if there is anything I can do, or throw my two cents > on, just let > me know. > > |
From: Robby L. <dig...@ho...> - 2002-12-31 19:03:22
|
Ex-php'er turned Diehard Cold Fusion Freak.. I'm not quite sure on the conversation level within this mailing list. But I would just like to say hello. And I think its a great idea and I'd like to be apart of (as much as my limited knowledge allows). "I'm" currently working on a couple of side projects of my own, xml and cfcs for the most part, But if there is anything I can do, or throw my two cents on, just let me know. --------------------------------------------------------- Robby sig... - ===================================================== - = currently using a spammable account, feel free to = - = email me for my personal email, if needed. = - ===================================================== - _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 3 months FREE*. http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_stopmorespam_3mf |
From: Jeremy F. <jfi...@ma...> - 2002-11-18 19:57:30
|
jfirsenbaum is my username - if that's what you mean by id. ----- Original Message -----=20 From: Nathan Dintenfass=20 To: mod...@li...=20 Sent: Monday, November 18, 2002 1:04 PM Subject: RE: [Modus-devs] Modus Developer's Guide Jeremy: Wow, this is great. I'll have to give it another look to make = substantive comments, but this is fantastic. BTW, do you have a = SourceForge ID? You're not even listed on the project team there ;) - n -----Original |
From: Nathan D. <na...@ch...> - 2002-11-18 18:01:55
|
Jeremy: Wow, this is great. I'll have to give it another look to make substantive comments, but this is fantastic. BTW, do you have a SourceForge ID? You're not even listed on the project team there ;) - n -----Original Message----- From: mod...@li... [mailto:mod...@li...]On Behalf Of Jeremy Firsenbaum Sent: Monday, November 18, 2002 9:49 AM To: modus devs Subject: [Modus-devs] Modus Developer's Guide Gentlemen It seems to me that we're in need of terminological clarity. There are still some facets of the redesigned framework we do not have a handle on, and much of the debate this past week has been about the meaning of the content object model. To this end I have put together a document that describes the code base as it currently stands. This is not meant to be prescriptive in any way - much of the design is still up for grabs in my opinion. I've tweaked things half a dozen times in the past week alone after some great suggestions by Nathan and Sean. I hope this addresses many of the concerns Nathan raised on Friday, some of which Sean has already addressed. Just writing this has caused be to get much clearer on what I've done - see the lengthy note on the contentType declaration in the Descriptors section. What I hope is that this will provide some grounding to our discussions and allow us to solidify the architecture so that we can concentrate on implementation. In other words, if we build a near-operational developer's guide, then we can easily build an operational framework - as Hal Helms always insists: code your documentation. -Jeremy |
From: Sean A C. <se...@co...> - 2002-11-17 19:13:25
|
On Friday, Nov 15, 2002, at 17:59 US/Pacific, Nathan Dintenfass wrote: > 1) I'm not totally clear about the render objects. What would a > pdfrenderer > look like, for instance? Would it be a generic way to make > contentObjects > render in PDF? I'm not so sure about that - seems way out of scope - but the renderer objects would render entities in different formats. For example, a content type that is a single value selected from a set of choices, could be rendered via a select drop-down in HTML or by a set of radio buttons in HTML - those would be two different renderer objects. > In general, I guess that I'd prefer a less verbose config file and > have to > just type out "com.mydomain.stuff.thing" instead of being able to type > just > "thing" because I have all that config data. Strikes me as somewhat > opaque, > or something like that -- but, maybe I'm insane that way ;) But I think Jeremy is suggesting the alias is optional anyway? > I guess it seems that rather than having a config file that tells me > pressRelease2 is a pressRelease that uses remoting, I'd rather have > some way > to have a remotingPressRelease and tell it that it should use the > pressReleaseDescriptor. I'm not sure it's a good example... :) > 3) I also must admit to feeling like I'm starting to get in over my > head as > far as the design patterns you are employing. I'm not yet under > water, but > it seems to be going there. But most of this complexity will be hidden from novice developers so it's OK. If Modus is going to be both useful and allow people to grow and for experts to extend it in new ways, it needs to be well-structured and it needs to leverage design patterns. > my fear is over abstracting > in places that won't be useful to the 90%+ of CF folks I think Jeremy's last comments about useful defaults will address this. My fear is that Modus will not be scalable - both performance wise (which I think we're addressing) and intellectually. Modus needs to support more than novice usage I think. > example of this would be that a com.changemedia.pressRelease had one > and > only one persister But if you hardcode that 1:1 relationship, you severely limit Modus - unnecessarily. "SOAP is not so much a means of transmitting data but a mechanism for calling COM objects over the Web." -- not Microsoft (surprisingly!) |
From: Sean A C. <se...@co...> - 2002-11-17 18:57:35
|
On Friday, Nov 15, 2002, at 06:04 US/Pacific, Jeremy Firsenbaum wrote: > Here's a revamped modus_settings that has two main sections: component=20= > definitions and contentobject definitions. The components are aliased=20= > for easy reference and defaults are=A0declared. The=20 > contentObjects=A0reference a contentType - note that this is the same=20= > pressrelease descriptor=A0for all but one of the objects. Any given=20 > contentType can have multiple contentObjects. Ah, this clarifies the object/type thing I was concerned about in the=20 previous email. > I see the components section as being optional. A default component=20 > definition should be part of the modus internals which=A0offers users = a=20 > set of built-in components to reference in their contentObjects. And=20= > for another level of simplicity, the=A0defaults make it unnecessary to=20= > even declare any components.=A0I think this cuts down on the = complexity=20 > for novices, but leaves the framework highly flexible and extensible.=A0= I think I agree with this. Good defaults help novices a lot. > I've also attached an image of the resulting framework. At the top is=20= > a map of Modus after it has been instantiated, at the bottom is a=20 > process diagram of how=A0one contenttype descriptor=A0is passed to=20 > different contentobjects. Not sure I really follow the bottom diagram but the top diagram is just=20= fine (although I still think contentObject will confuse people - it=20 confused me! - since it is really a *type* not an *object*). Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood |
From: Sean A C. <se...@co...> - 2002-11-17 18:53:56
|
On Thursday, Nov 14, 2002, at 17:10 US/Pacific, Jeremy Firsenbaum wrote: > Not using cfapplication: please explain what the issue is here.=A0In=20= > what way would=A0this hamper a developer by making it a requirement?=20= > Using the application name seems to be the cleanest way to provide=20 > distinct containers for multiple Modus apps on the same server. I think the core Modus machinery belongs in server scope - all the=20 services - and I'm beginning to agree with Nathan that it shouldn't=20 *require* application scope in order to work. Nathan seems to be=20 arguing that *if* an application enables application scope then Modus=20 *may* take advantage of it to provide 'conveniences'. I think that is a=20= good point. In a multi-application environment, if developers do not=20 enable application scope, then there is one single namespace and all of=20= their Modus stuff has to live in it - it's the developers'=20 responsibility to make sure things don't clash. > One contentObject, one persister: yes, actually, the current set up=20 > creates a distinct set of components for each contentObject. I assume you mean "...for each contentObject type"? > When I was referring to the application-level setting of components I=20= > meant that certain components, like the facade=A0and validator, would = be=20 > the same for all contentObjects. "...would be the same *per application* for all contentObject *types*"? > Each contentObject still gets its own distinct instantiation "Each contentObject *type* still..."? > Extending contentObjects: currently the registry is not set up to=20 > handle this, but there's nothing preventing it. You could add an=20 > extends attribute to the descriptor and have the registry figure out=20= > which properties needed to be pulled from the parent. Quite simple to=20= > implement actually, so I'll give that a shot when I get some of the=20 > other things working. That would be quite neat although I think the more natural thing would=20= be for the CFCs to extend others and just have the XML descriptor=20 reference the extended CFC (and have Modus locate the descriptor for=20 the parent CFC). > Scope and namespace for Modus API: this is a biggy, as it's the only=20= > real thing users will have to worry about. Here are the contenders: > =A0 > a. get("pressrelease") My basic preference. Custom tags either need to include the UDF library=20= file or use the extended call format (c/d). The functions probably need=20= a "modus_" prefix however. > b. modus.get("pressrelease") I don't like this (because it seems to introduce an unnecessary local=20 alias). > c. server.modus.get("pressrelease") > d. server.modus.get("org.bacfug.pressrelease") This is where I think the application scope alias for=20 org.bacfug.pressrelease could be handy. In fact, based on other=20 language experience, generally having an *optional* alias for things=20 like this can be useful. But I have no strong feelings on it. > Obviously A and B would not be available within custom tags. I'm=20 > willing to live with that, argument already being made that custom tag=20= > developers are used to handling scope issues. Agreed - see above. > While D is certainly a possibility, it really only makes sense if we=20= > need to avoid using cfapplication - I do think it would make code=20 > rather "onerous" to read. See above. I think it's OK to allow an alias for a type but I don't=20 think we should require it. I'm not sure how best to go about this=20 right now. It's nice to allow an alias so that code written for=20 "pressRelease" can be reused for different (but similar)=20 implementations of a press release type. My team worked exclusively=20 with fully qualified type names and did *not* find it onerous. > Right now I vote for the mix of B and C - maybe I'm not worked up over=20= > the "inconsistency" because I don't really use custom tags for > = display. But a lot of people do and I think will continue to do so. I vote for a=20= & d so we're on a bit of a split this time around :) > By the way, I've found the same loss of pageContext in server-scoped=20= > cfcs.=A0I didn't think was an issue, but it seems to be - Sean? Yes, all shared scopes suffer this bug. Rule: never output HTML from a=20= CFC :) Nathan wrote: > That is one of the reasons I would propose that things like a=20 > persister are tied to a contentObject, not to an application. No, see below. > I think that org.bacfug.pressRelease vs org.firsenbaum.pressRelease=A0is= =20 > still a better way to do it than simply "pressRelease" -- IMO Modus=20 > should not require CFAPPLICATION to run at all. Although I think cfapplication is 'best practice' I'm beginning to=20 agree to with Nathan that Modus should not *require* it. All core=20 services in server scope. Specific instances in application scope if=20 enabled else server scope (and it is the developers' responsibility). > I think it's probably OK that org.bacfug.pressRelease has a single=20 > persister, no? No. Here I'm with Jeremy. I take your org.bacfug.pressRelease and plonk=20= it down in my application where I use my own persister. Must be=20 possible to do. Content object types must be persistence-neutral. > In the stuff I was working on I had succesfully extended=20 > modustest.pressRelease with modustest.specialPressRelease -- which had=20= > all the same "properties" of the pressRelease and then added some (and=20= > could override some too).=A0 Can you see doing that with the setup you=20= > now have?=A0 It would be a "good thing" I think (??). Yes, this needs to be possible. See my comments above. > I think if a developer wants to build a way to make=20 > org.bacfug.pressRelease into "pressRelease" for the sake of their own=20= > application that is fine. Agreed. > I could also see building some kind of service that does this.=A0 Do = you=20 > think it would be too onerous to require explicit names for object=20 > types? No, I don't. My team did it that way - longhand - and no one complained. Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood |
From: Nathan D. <na...@ch...> - 2002-11-16 01:57:31
|
Jeremy: You're clearly doing a fair amount of work. Sorry I've not been keeping up with it as much as I should. A couple questions that came to mind immediately: 1) I'm not totally clear about the render objects. What would a pdfrenderer look like, for instance? Would it be a generic way to make contentObjects render in PDF? 2) We may have to just agree to disagree about the need to have different aliases (i.e.: "pressRelease1" and "pressRelease2") to describe the same descriptor and the need to have the same alias (i.e.: "pressRelease") to describe different descriptors (i.e.: "org.bacfug.pr" and "com.macromedia.pr"). That is, my personal style would be to decouple contentObjects, their descriptors, persisters, descriptors, etc. from an "Application." Which is not to say that Modus might not want to build out some kind of application-level abstractions, but I'm just not sure why those need to relate directly to the contentObject layers. In general, I guess that I'd prefer a less verbose config file and have to just type out "com.mydomain.stuff.thing" instead of being able to type just "thing" because I have all that config data. Strikes me as somewhat opaque, or something like that -- but, maybe I'm insane that way ;) I guess it seems that rather than having a config file that tells me pressRelease2 is a pressRelease that uses remoting, I'd rather have some way to have a remotingPressRelease and tell it that it should use the pressReleaseDescriptor. 3) I also must admit to feeling like I'm starting to get in over my head as far as the design patterns you are employing. I'm not yet under water, but it seems to be going there. I haven't put the time in necessary to fully grok the last two chunks of code you posted, but my fear is over abstracting in places that won't be useful to the 90%+ of CF folks who won't be able to quickly embrace the various levels that the components are introducing. I'm not saying it's yet there, but given the skills the rest of you have I'll be happy to represent the "dummy" crowd ;) Part of it is that I thought of some of the steps I was taking initially as akin to "denormalizing" a database schema for performance. Except in my case it was "deabstracting" certain things to make life easier. I guess an example of this would be that a com.changemedia.pressRelease had one and only one persister -- to me, the process of having to define my raw data storage separately from the way I might persist it or manipulate it seemed like overhead I was doing away with. I was OK with it partially because I could always say otherKindOfPressRelease extends pressRelease and just changes the persister it uses -- I was imbuing the contentObject descriptor (which was CFPROPERTY and is now moving to XML) with more meaning than just being akin to a DDL in a database. Yes, this violates many pure design abstractions, but for most of the apps I've ever seen built it would save a lot of time and energy that would be better spent on higher order functionality. I'm not saying we shouldn't do the "service model", and I really like where you are going with modus components (though, perhaps those should be called something like "plugins" to avoid confusion with CF components) because that is much more easily extended than where I was going with the monolithic baseContentObject. I also don't want to discourage the excellent work and thinking that you're doing (and I'm not!!!). 4) Can you help me understand how you are using: defaultPathToDescriptors="C:\CFusionMX\wwwroot\modustest\descriptors" pathToModus="C:\CFusionMX\wwwroot\org\bacfug\modus" In looking at your code, I see use of things like "org.bacfug.modus...." -- how would this reconcile if pathToModus did not live off the web root? I'd also be happy to do away with the need to have each "application" define where it's descriptors are and have that be part of the call to a Modus initializing script included in Application.cfm (or in some other way globally). Or, to just have a developer be explicit about where descriptors are as they config their application. BTW, I am not saying I'm against Application.cfm, only that if possible I'd prefer to not require CFAPPLICATION or to use application variables by default. The short answer to this is that I have been making my applications with CFAPPLICATION since the CFLOCK issues cropped up -- global vars went into request vars and I went back to using serialized sessions out of the database (which had the added benefit of making my applications very easily clusterable). In MX I'm less concerned about application scoped variables and CFAPPLICATION in general, but it feels like an encumbrance more than a liberator. Perhaps there is a deeper discussion to have about the role of Modus and the nature of a Modus contentObject, though. Perhaps a compromise here would be to have the global modus config file have a notion of "profiles", each of which can have different defaults (and there would be a default profile). I could then tell a descriptor (or a facade, perhaps) which profile to use. That would get you the config level short-cuts and prevent the need for CFAPPLICATION and application-specific configuration of Modus (and has the benefit of being able to use a single profile in multiple applications, and for third-parties to build out profiles and ship them as a fairly tight addition to an existing Modus installation). We might then have something like: <profiles> <profile name="bacfug"> <components> <persister type="org.bacfug.modus.persistence.fileSystemSerialized"/> </components> </profile> <defaultProfile> <components> <facade type="org.bacfug.modus.facades.webfacade"/> <validator type="org.bacfug.modus.validation.validator"/> <renderer type="org.bacfug.modus.rendering.baserenderer"/> <persister type="org.bacfug.modus.persistence.simpleobjectinstance"/> </components> </defaultProfile> </profiles> Where the defaultProfile sets all defaults and each profile can then override one or more of them (and possibly add new ones). Though, personally, I think it would be sufficient to just define defaults for all components, then let a developer override those in the proper place (facade or descriptor, depending on how things shake out). 5) I do think that having the ability to "extend" a descriptor is fairly critical, but I can see how that will be relatively straight-forward in your setup. 6) I agree we shouldn't get hung up on modus.get() vs. server.modus.get() -- though, I do think it's worth having a convention. My preference is server.modus.... for basically everything as the "standard" way to code in Modus. OK, gotta run . . . - n |
From: Sean A C. <se...@co...> - 2002-11-15 07:17:55
|
On Thursday, Nov 14, 2002, at 15:12 US/Pacific, Nathan Dintenfass wrote: > That is one of the reasons I would propose that things like a=20 > persister are tied to a contentObject, not to an application. I'm not sure. I'd like to be able to create 'bindings' (for want of a=20 better word) for content objects to multiple persisters and renderers -=20= that's kind of what I think of the facade as doing: acting as the=20 controller for a specific persister/renderer binding to a named content=20= object. > I think that org.bacfug.pressRelease vs org.firsenbaum.pressRelease=A0is= =20 > still a better way to do it than simply "pressRelease" True, I have no problem with requiring explicitly qualified content=20 object names (users can always create their own aliases to the object=20 factory). > IMO Modus should not require CFAPPLICATION to run at all. Um, well, I'm not sure I agree here. Requiring an application name is=20 no big deal. As long as it works with the anonymous application...=20 Which may become a common trick to share scope data with Java. I'm not=20= quite sure what 'appName' looks like in the anonymous application=20 (Jeremy?). > I think it's probably OK that org.bacfug.pressRelease has a single=20 > persister, no? No. See above. > I guess that with your setup you won't be able to extend an existing=20= > type. Not sure why you think that. You can extend a type and then specify=20 that extended type in the descriptor and it should work. The services=20 model just decouples type definitions from instances - that still=20 allows inheritance. Or am I missing your point? > Personally, if it ends up being server.modus.get() I will always use=20= > that rather than setting modus =3D server.modus. I agree. I'm not too keen on the 'shortcut' and I think developers will=20= quickly get used to this idea of server.<uniqueinstance>.<method>() in=20= the CFC world (I sure wish we'd gotten 'static' methods to work=20 properly in CFMX... they existed in a very early build but then they=20 went away - to simplify the model, I suppose). > The server or request scope are better than the application scope=20 > because they don't require CFAPPLICATION and they get around the nasty=20= > issue of CFC's losing the proper page context. I'm with you on that. Server scope is my preferred scope anyway for=20 caching. "SOAP is not so much a means of transmitting data but a mechanism for calling COM objects over the Web." -- not Microsoft (surprisingly!) |
From: Jeremy F. <jfi...@ma...> - 2002-11-15 06:54:20
|
Nathan - there's a lot in there so I'll try to address each of the = issues individually. Naming conventions for contentObjects: with the xml format you actually = can use a name like org.bacfug.pressrelease. The simple name was used to = simplify typing, but using the fully qualified name is one way around = the application-scoped cfc library. Not using cfapplication: please explain what the issue is here. In what = way would this hamper a developer by making it a requirement? Using the = application name seems to be the cleanest way to provide distinct = containers for multiple Modus apps on the same server. One contentObject, one persister: yes, actually, the current set up = creates a distinct set of components for each contentObject. When I was = referring to the application-level setting of components I meant that = certain components, like the facade and validator, would be the same for = all contentObjects. Each contentObject still gets its own distinct = instantiation - again, this is still being worked out so I'm sorry if = this wasn't clear. When you get a chance, run the app and do a dump of = server.modus - you'll see all of the pieces layed out. Extending contentObjects: currently the registry is not set up to handle = this, but there's nothing preventing it. You could add an extends = attribute to the descriptor and have the registry figure out which = properties needed to be pulled from the parent. Quite simple to = implement actually, so I'll give that a shot when I get some of the = other things working. Scope and namespace for Modus API: this is a biggy, as it's the only = real thing users will have to worry about. Here are the contenders: a. get("pressrelease") b. modus.get("pressrelease") c. server.modus.get("pressrelease") d. server.modus.get("org.bacfug.pressrelease") Obviously A and B would not be available within custom tags. I'm willing = to live with that, argument already being made that custom tag = developers are used to handling scope issues. While D is certainly a = possibility, it really only makes sense if we need to avoid using = cfapplication - I do think it would make code rather "onerous" to read. = Right now I vote for the mix of B and C - maybe I'm not worked up over = the "inconsistency" because I don't really use custom tags for display. = Anyone is free to use C exclusively - there could even be a boolean in = modus_settings to turn the shorthand on or off. None of this is set in = stone, and it's proven simple to change, so let's not get too hung up = over it. When the whole framework is clearer I think it will be easier = to make a decision. By the way, I've found the same loss of pageContext in server-scoped = cfcs. I didn't think was an issue, but it seems to be - Sean? That is one of the reasons I would propose that things like a = persister are tied to a contentObject, not to an application. I think = that org.bacfug.pressRelease vs org.firsenbaum.pressRelease is still a = better way to do it than simply "pressRelease" -- IMO Modus should not = require CFAPPLICATION to run at all. I think it's probably OK that = org.bacfug.pressRelease has a single persister, no? I guess that with = your setup you won't be able to extend an existing type. In the stuff I = was working on I had succesfully extended modustest.pressRelease with = modustest.specialPressRelease -- which had all the same "properties" of = the pressRelease and then added some (and could override some too). Can = you see doing that with the setup you now have? It would be a "good = thing" I think (??). Custom tag developers are indeed used to scope issues -- this is why = many applications now have something like application.lib.someUDF() or = request.lib.someUDF() -- so they can be used in custom tags. = Personally, if it ends up being server.modus.get() I will always use = that rather than setting modus =3D server.modus. Again, I think it = would be good if all Modus code looks basically like all other Modus = code, so I would encourage a convention that works both inside of custom = tags AND in "normal" templates. The server or request scope are better = than the application scope because they don't require CFAPPLICATION and = they get around the nasty issue of CFC's losing the proper page context. I think if a developer wants to build a way to make = org.bacfug.pressRelease into "pressRelease" for the sake of their own = application that is fine. I could also see building some kind of = service that does this. Do you think it would be too onerous to require = explicit names for object types? - n -----Original Message----- From: mod...@li... = [mailto:mod...@li...]On Behalf Of Jeremy = Firsenbaum Sent: Thursday, November 14, 2002 2:37 PM To: mod...@li... Subject: Re: [Modus-devs] Re: New Code Posted Well, I just confirmed this. The included UDFs are not available to = custom tags. This leaves us with a big decision. One of Nathan's concerns when discussing the UDF was approach was = defining a namespace for Modus. I think this is a more powerful argument = for the static CFC library than custom tag access. Seems to me that = custom tag developers should be used to scope issues as these were the = first real way to do encapsulation with CF.=20 I really prefer the modus prefix on the functions as it defines a = clear namespace for the API. One of the things I'm working on now is an = application-scope cfc to hold the API functions. This is similar to the = example I gave earlier where server.modus.udflib is referenced as modus = in Application.cfm. Custom tag developers would need to use the full = path in this case. As for many applications not using the cfapplication tag, that's = news to me. The whole framework depends on the application name to allow = various Modus apps to be run concurrently on the same server without = name conflicts. Look at the way the registry constructs the components: server.modus[appName].persister[componentName]; The UDF lib uses the applicationname to find the appropriate facade = to call. This is why I'm looking into making the UDF lib a static = application CFC. The loss of pageContext bug prevents CFCs from = accessing the application scope. Each application would have its own = static lib that maintains the applicationname in the instance scope. = Thus normal page calls would look like modus.get() and custom tags would = need to do application.modus.udflib.get(), or whatever the static lib = winds up being called.=20 If there's another way of doing this and still preventing name = conflicts (my pressrelease and your pressrelease on the same server) = then shout it out. This is crucial to the way Modus gets used so we = should take the time to get it right. -Jeremy ----- Original Message -----=20 From: Nathan Dintenfass=20 To: mod...@li...=20 Sent: Thursday, November 14, 2002 4:25 PM Subject: RE: [Modus-devs] Re: New Code Posted > > Given that we're moving to "Modus as service" as our model, > > server.modus makes the most sense to me (why copy it all into = the > > request scope, after all?). Make sense? > > Yes, although I still prefer the UDF approach :) Well, but you still need to put it in the server or request or = application (or session) scope to make it available to custom tags. I think server.modus is just a struct, not a CFC instance. So, putting = UDF's in that struct should not be a big deal. This assumes the user won't = do something stupid like structClear(server.modus), but I suppose = there's little to be done about that. - n ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing = your web site with SSL, click here to get a FREE TRIAL of a Thawte = Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Modus-devs mailing list Mod...@li... https://lists.sourceforge.net/lists/listinfo/modus-devs |
From: Jeremy F. <jfi...@ma...> - 2002-11-15 06:38:06
|
Sent a message about an hour and didn't make it. |
From: Nathan D. <na...@ch...> - 2002-11-14 23:10:13
|
That is one of the reasons I would propose that things like a persister are tied to a contentObject, not to an application. I think that org.bacfug.pressRelease vs org.firsenbaum.pressRelease is still a better way to do it than simply "pressRelease" -- IMO Modus should not require CFAPPLICATION to run at all. I think it's probably OK that org.bacfug.pressRelease has a single persister, no? I guess that with your setup you won't be able to extend an existing type. In the stuff I was working on I had succesfully extended modustest.pressRelease with modustest.specialPressRelease -- which had all the same "properties" of the pressRelease and then added some (and could override some too). Can you see doing that with the setup you now have? It would be a "good thing" I think (??). Custom tag developers are indeed used to scope issues -- this is why many applications now have something like application.lib.someUDF() or request.lib.someUDF() -- so they can be used in custom tags. Personally, if it ends up being server.modus.get() I will always use that rather than setting modus = server.modus. Again, I think it would be good if all Modus code looks basically like all other Modus code, so I would encourage a convention that works both inside of custom tags AND in "normal" templates. The server or request scope are better than the application scope because they don't require CFAPPLICATION and they get around the nasty issue of CFC's losing the proper page context. I think if a developer wants to build a way to make org.bacfug.pressRelease into "pressRelease" for the sake of their own application that is fine. I could also see building some kind of service that does this. Do you think it would be too onerous to require explicit names for object types? - n -----Original Message----- From: mod...@li... [mailto:mod...@li...]On Behalf Of Jeremy Firsenbaum Sent: Thursday, November 14, 2002 2:37 PM To: mod...@li... Subject: Re: [Modus-devs] Re: New Code Posted Well, I just confirmed this. The included UDFs are not available to custom tags. This leaves us with a big decision. One of Nathan's concerns when discussing the UDF was approach was defining a namespace for Modus. I think this is a more powerful argument for the static CFC library than custom tag access. Seems to me that custom tag developers should be used to scope issues as these were the first real way to do encapsulation with CF. I really prefer the modus prefix on the functions as it defines a clear namespace for the API. One of the things I'm working on now is an application-scope cfc to hold the API functions. This is similar to the example I gave earlier where server.modus.udflib is referenced as modus in Application.cfm. Custom tag developers would need to use the full path in this case. As for many applications not using the cfapplication tag, that's news to me. The whole framework depends on the application name to allow various Modus apps to be run concurrently on the same server without name conflicts. Look at the way the registry constructs the components: server.modus[appName].persister[componentName]; The UDF lib uses the applicationname to find the appropriate facade to call. This is why I'm looking into making the UDF lib a static application CFC. The loss of pageContext bug prevents CFCs from accessing the application scope. Each application would have its own static lib that maintains the applicationname in the instance scope. Thus normal page calls would look like modus.get() and custom tags would need to do application.modus.udflib.get(), or whatever the static lib winds up being called. If there's another way of doing this and still preventing name conflicts (my pressrelease and your pressrelease on the same server) then shout it out. This is crucial to the way Modus gets used so we should take the time to get it right. -Jeremy ----- Original Message ----- From: Nathan Dintenfass To: mod...@li... Sent: Thursday, November 14, 2002 4:25 PM Subject: RE: [Modus-devs] Re: New Code Posted > > Given that we're moving to "Modus as service" as our model, > > server.modus makes the most sense to me (why copy it all into the > > request scope, after all?). Make sense? > > Yes, although I still prefer the UDF approach :) Well, but you still need to put it in the server or request or application (or session) scope to make it available to custom tags. I think server.modus is just a struct, not a CFC instance. So, putting UDF's in that struct should not be a big deal. This assumes the user won't do something stupid like structClear(server.modus), but I suppose there's little to be done about that. - n ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Modus-devs mailing list Mod...@li... https://lists.sourceforge.net/lists/listinfo/modus-devs |
From: Jeremy F. <jfi...@ma...> - 2002-11-14 22:57:30
|
Just an update: got the application-scoped library cfc working, so this = is a possibility.=20 ----- Original Message -----=20 From: Jeremy Firsenbaum=20 To: mod...@li...=20 Sent: Thursday, November 14, 2002 5:36 PM Subject: Re: [Modus-devs] Re: New Code Posted Well, I just confirmed this. The included UDFs are not available to = custom tags. This leaves us with a big decision. One of Nathan's concerns when discussing the UDF was approach was = defining a namespace for Modus. I think this is a more powerful argument = for the static CFC library than custom tag access. Seems to me that = custom tag developers should be used to scope issues as these were the = first real way to do encapsulation with CF.=20 I really prefer the modus prefix on the functions as it defines a = clear namespace for the API. One of the things I'm working on now is an = application-scope cfc to hold the API functions. This is similar to the = example I gave earlier where server.modus.udflib is referenced as modus = in Application.cfm. Custom tag developers would need to use the full = path in this case. As for many applications not using the cfapplication tag, that's news = to me. The whole framework depends on the application name to allow = various Modus apps to be run concurrently on the same server without = name conflicts. Look at the way the registry constructs the components: server.modus[appName].persister[componentName]; The UDF lib uses the applicationname to find the appropriate facade to = call. This is why I'm looking into making the UDF lib a static = application CFC. The loss of pageContext bug prevents CFCs from = accessing the application scope. Each application would have its own = static lib that maintains the applicationname in the instance scope. = Thus normal page calls would look like modus.get() and custom tags would = need to do application.modus.udflib.get(), or whatever the static lib = winds up being called.=20 If there's another way of doing this and still preventing name = conflicts (my pressrelease and your pressrelease on the same server) = then shout it out. This is crucial to the way Modus gets used so we = should take the time to get it right. -Jeremy https://lists.sourceforge.net/lists/listinfo/modus-devs |
From: Sean A C. <se...@co...> - 2002-11-14 22:56:54
|
On Thursday, Nov 14, 2002, at 14:36 US/Pacific, Jeremy Firsenbaum wrote: > Well, I just confirmed this. The included UDFs are not available to=20 > custom tags. Er, oops, yes... silly me... > One of Nathan's concerns when discussing the UDF was approach was=20 > defining a namespace for Modus. I think this is a more powerful=20 > argument for the static=A0CFC library than custom tag access. Seems to=20= > me that custom tag developers should be used to scope issues as these=20= > were the first real way to do encapsulation with CF. cfinvoke can be used to invoke any of those static methods but there's=20= no script equivalent (since it requires an instance) so we're back to=20 server.modus.functionName() again... > As for many applications not using the cfapplication tag, that's news=20= > to me. The whole framework depends on the application name to allow=20 > various Modus apps to be run concurrently on the same server without=20= > name conflicts. I agree that requiring Application.cfm / cfapplication is no big deal.=20= Even Fusebox MX requires Application.cfm! :) "I have always wished that my computer would be as easy to use as my telephone. My wish has come true - I no longer know how to use my telephone." -- Bjarne Stroustrup |
From: Jeremy F. <jfi...@ma...> - 2002-11-14 22:36:57
|
Well, I just confirmed this. The included UDFs are not available to = custom tags. This leaves us with a big decision. One of Nathan's concerns when discussing the UDF was approach was = defining a namespace for Modus. I think this is a more powerful argument = for the static CFC library than custom tag access. Seems to me that = custom tag developers should be used to scope issues as these were the = first real way to do encapsulation with CF.=20 I really prefer the modus prefix on the functions as it defines a clear = namespace for the API. One of the things I'm working on now is an = application-scope cfc to hold the API functions. This is similar to the = example I gave earlier where server.modus.udflib is referenced as modus = in Application.cfm. Custom tag developers would need to use the full = path in this case. As for many applications not using the cfapplication tag, that's news to = me. The whole framework depends on the application name to allow various = Modus apps to be run concurrently on the same server without name = conflicts. Look at the way the registry constructs the components: server.modus[appName].persister[componentName]; The UDF lib uses the applicationname to find the appropriate facade to = call. This is why I'm looking into making the UDF lib a static = application CFC. The loss of pageContext bug prevents CFCs from = accessing the application scope. Each application would have its own = static lib that maintains the applicationname in the instance scope. = Thus normal page calls would look like modus.get() and custom tags would = need to do application.modus.udflib.get(), or whatever the static lib = winds up being called.=20 If there's another way of doing this and still preventing name conflicts = (my pressrelease and your pressrelease on the same server) then shout it = out. This is crucial to the way Modus gets used so we should take the = time to get it right. -Jeremy ----- Original Message -----=20 From: Nathan Dintenfass=20 To: mod...@li...=20 Sent: Thursday, November 14, 2002 4:25 PM Subject: RE: [Modus-devs] Re: New Code Posted > > Given that we're moving to "Modus as service" as our model, > > server.modus makes the most sense to me (why copy it all into the > > request scope, after all?). Make sense? > > Yes, although I still prefer the UDF approach :) Well, but you still need to put it in the server or request or = application (or session) scope to make it available to custom tags. I think server.modus is just a struct, not a CFC instance. So, putting UDF's = in that struct should not be a big deal. This assumes the user won't do something stupid like structClear(server.modus), but I suppose there's little to be done about that. - n ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing=20 your web site with SSL, click here to get a FREE TRIAL of a Thawte=20 Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Modus-devs mailing list Mod...@li... https://lists.sourceforge.net/lists/listinfo/modus-devs |
From: Nathan D. <na...@ch...> - 2002-11-14 21:23:51
|
> > Given that we're moving to "Modus as service" as our model, > > server.modus makes the most sense to me (why copy it all into the > > request scope, after all?). Make sense? > > Yes, although I still prefer the UDF approach :) Well, but you still need to put it in the server or request or application (or session) scope to make it available to custom tags. I think server.modus is just a struct, not a CFC instance. So, putting UDF's in that struct should not be a big deal. This assumes the user won't do something stupid like structClear(server.modus), but I suppose there's little to be done about that. - n |
From: Sean A C. <se...@co...> - 2002-11-14 21:16:41
|
On Thursday, Nov 14, 2002, at 13:01 US/Pacific, Nathan Dintenfass wrote: > Yes, exactly.=A0 A facade is not a User Interface.=A0 Thus, things = that=20 > are for outputting to a user interface should not be called a facade > = ;) The *renderer* is what creates the UI portions. The facade could=20 equally be called controller in this context I guess. > The issue with custom tags is that they don't have access to the scope=20= > of the calling page (absent the very ugly "caller." syntax). Ah, I'm with you now. That's why I suggested (global) UDFs so that=20 scope was not an issue. > Given that we're moving to "Modus as service" as our model,=20 > server.modus makes the most sense to me (why copy it all into the=20 > request scope, after all?).=A0 Make sense? Yes, although I still prefer the UDF approach :) "I can smell your brains!" -- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html |