He3 community input (custom tag paths/mappings)

For various types of features we would like to implement in He3, we need the ability to locate files that are defined by runtime information which won't be available. Examples of this include resolving cfincludes, custom tag calls, and CFC dot notation references. One way to solve this is for projects in He3 to be configured with custom tag paths and mappings that match the settings in the target platform. That leads to a few implications. First, it requires the developer to actually configure information in a project. I know DWMX's project configuration annoyed me when I was used to just pointing Studio at a file system directory. Second, the project's settings could get out of sync with the target platform thus causing unexpected behavior. Any thoughts on the proposed solution? -Matt

>First, it >requires the developer to actually configure information in a project. >I know DWMX's project configuration annoyed me when I was used to just >pointing Studio at a file system directory Matt, The key in to ensure that I can can get a feel for functionality without slogging my way through a project setup. (Perhaps bundle a series of simple "Hello, World!" projects that can be used to get a feel for things.) Once I'm sold, the minor investment in setup time won't be a big deal. >Second, the project's >settings could get out of sync with the target platform thus causing >unexpected behavior. Throwing out ideas: - Let me tell the app which files contain vital settings (hopefully, there won't be more than a few per project), and optionally (by default?) remind me to check my project settings when changes are made to those files. - Let me define the settings in the project info, and then automatically insert the values into my files wherever I enter something like [$He3.CFCpath$]. If I change the value, sweep through and update my code. -- Roger Benningfield work: http://journurl.com/ blog: http://admin.mxblogspace.journurl.com/

----- Excess quoted text cut - see Original Post for more ----- Do you see people's settings changing often? Normally (well, for my projects anyway), the settings (DSN, mapping) are setup at the beginning and never change. The main thing that _does_ change are the files. So if your product's concept of projects would auto include all files in a folder, then I think it would be fine. I'd have no issue setting up things like the DSN and mapping since this would only need to be done once per project.

----- Excess quoted text cut - see Original Post for more ----- I'd also point out, that there are times when I want to use full featured editor, but don't necessarily need/want to set up a project just to edit a couple of rogue files. So, I want both a project view and a normal o/s file view--depending on how I'm working at the moment. - Dan

> I'd also point out, that there are times when I want to use > full featured editor, but don't necessarily need/want to set > up a project just to edit a couple of rogue files. > > So, I want both a project view and a normal o/s file > view--depending on how I'm working at the moment. > A huge +1 on this. I hate editors that make me jump through hoops just to do quick edits. Projects should _not_ be required, period. If it means I lose features (like maybe right clicking on a cfinclude and loading the file it loads), thats fine. -Ray

I guess I don't need to point out my +1 here. Anyway, my thinking is that if you don't provide the information needed the editor will continue to function, but what offer the same functionality. -Matt On May 31, 2004, at 10:46 AM, Raymond Camden wrote: ----- Excess quoted text cut - see Original Post for more -----

Matt, >I guess I don't need to point out my +1 here. Anyway, my thinking is >that if you don't provide the information needed the editor will >continue to function, but what offer the same functionality. I figured that's the way you were doing things, but I figured I might as well re-iterate my preference. Also, one thing I'd like to see in a CF IDE is for the pounded variables to be color coded--I think not color coding variables in CF Studio was a big oversight. (i.e #variables.someVar# should be something that's color coded.) - Dan

How about a server component that would somehow translate the location of mappings/tags? I think that would allow you to setup a server once instead of each individual project. Steve Nelson   _____ Sent: Sunday, May 30, 2004 6:05 PM To: CF-Talk Subject: He3 community input (custom tag paths/mappings) For various types of features we would like to implement in He3, we need the ability to locate files that are defined by runtime information which won't be available. Examples of this include resolving cfincludes, custom tag calls, and CFC dot notation references. One way to solve this is for projects in He3 to be configured with custom tag paths and mappings that match the settings in the target platform. That leads to a few implications. First, it requires the developer to actually configure information in a project. I know DWMX's project configuration annoyed me when I was used to just pointing Studio at a file system directory. Second, the project's settings could get out of sync with the target platform thus causing unexpected behavior. Any thoughts on the proposed solution? -Matt   _____  

> How about a server component that would somehow translate the location > of >  mappings/tags? I think that would allow you to setup a server once > instead >  of each individual project. > That would require that each project know what server to connect to since a developer may want to have different projects deploy to different servers. Further, it would require that the IDE be able to connect to the server during development, which would be annoying on a plane for example. Although, that could probably be solved with some sort of caching/synchronization routine. I certainly can see that it would be annoying to setup project after project with the same settings. However, I am not sure what you are suggesting is any better because of what I mentioned above. -Matt

That's not really what I'm thinking. My thought is to point the IDE to a single url (per development server) that returns stuff like this (in some xml format): Mappings: "/" = d:\inetpub\wwwroot "/funkychicken" = d:\inetpub\wwwroot\iama\funkychicken Tags: <cf_chickendance> = d:\inetpub\wwwroot\iama\funkychicken\chickendance.cfm This information could easily be determined by CF and would work just as fine on a 127.0.0.1 IP as it would a public IP. If the information is changed in the cf server, it would automatically reflect here. It could check the server once when the IDE is loading up then cache it like you're saying.  This clearly doesn't solve everything, but it could be a start. If you can make this setup automated, that would be preferable. What it doesn't solve are things like dynamic includes, such as: <cfinclude template="#funkychicken#"> To do that you either need to actually run the template or create a CFML engine. Steve   _____ Sent: Wednesday, June 02, 2004 10:09 PM To: CF-Talk Subject: Re: He3 community input (custom tag paths/mappings) > How about a server component that would somehow translate the location > of >  mappings/tags? I think that would allow you to setup a server once > instead >  of each individual project. > That would require that each project know what server to connect to since a developer may want to have different projects deploy to different servers. Further, it would require that the IDE be able to connect to the server during development, which would be annoying on a plane for example. Although, that could probably be solved with some sort of caching/synchronization routine. I certainly can see that it would be annoying to setup project after project with the same settings. However, I am not sure what you are suggesting is any better because of what I mentioned above. -Matt   _____