t; To do that you either need to actually run the
template or create a CFML engine.
Steve
_
From: Matt Liotta [mailto:[EMAIL PROTECTED]
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 w
> 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 di
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, an
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 p
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:
> > I'd also point out, that there are ti
> 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 hu
>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,
>th
> 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 thi
>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
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 p
10 matches
Mail list logo