Re: Project templates
Re: Project templates
- Subject: Re: Project templates
- From: Philip Aker <email@hidden>
- Date: Mon, 14 Jul 2008 06:16:28 -0700
On 08-07-14, at 04:43, Karan, Cem (Civ, ARL/CISD) wrote:
I apologize for taking so long to reply; I was sent on a trip to a
location without email access. I am now finally catching up on
things.
I was hoping to go with something closer to #1; my thought is that
we can actually tie in our own template mechanisms that get called
by Xcode, so Xcode doesn't have to do any heavy lifting, and to
allow us maximum flexibility. Maybe this will help:
1) User fires up Xcode, and selects an icon to create a new project.
The icon is actually a separate helper application that knows how to
talk to Xcode.
2) The application comes up and presents whatever interface is
needed. This might be one thing for C/C++/Objective-C files, another
for Java, another for Interface Builder, etc.
3) After entering in all the relevant fields, the application uses
Xcode's Applescript dictionary to create the project.
This reduces the amount of work the Xcode team faces, while at the
same time guaranteeing the maximum flexibility for us as users. For
example, maybe Xcode can have settings as to which user it runs the
helper application as. Then, the user can set the helper to run
with the user's permissions. The application may then be a
networked application, so when the user generates a new project
file, the application goes across the network to a company-global
template. If the template is updated, the user has access to it
immediately. Xcode doesn't need to have network capabilities, but
it gets that ability via this interface.
As I mentioned before, this approach also reduces the work the Xcode
team faces; this is important, because they've known that a good
template mechanism is necessary for a long time, but they don't have
the resources to implement one. If we make things as simple as
possible, then it is more likely that they'll implement it.
Does that make sense?
I have spent some time on #1 but it's no-where near being workable
yet. The specific problem is that for the purposes of translation to
and from XML, there are a couple of places where what would normally
be considered an XML element attribute is currently mapping to an
attribute having an embedded element (i.e. either a plist 'array' or
'dict' and a no-no in XML attributes). I'm not sure how to best handle
the situation with a generic mapping code. What I don't want to do is
have a big switch to address oddball cases. It would be too much for
me to examine every possible project type for these possibilities.
Since the format is not documented, all I can say right now is "stay
tuned"…
I just want to make sure we're thinking exactly the same thing
here; is the XML template being supplied by Xcode to a script, for
the script to modify, or is the script supplying Xcode an XML file,
from which Xcode builds a new project?
Close to #2. It's creating an Xcode project directly -- I needed
some time to create proof of concept so sorry for the delayed
response. At this point, I can provide Xcode a project that is
indistinguishable from an instantiated Empty Project template
choice. For folks familiar with Xcode's AppleScript dictionary,
this might be all that they would need to create projects dynamically.
I'm reasonably certain that I can advance the state to incorporate
more of the elements in the XML example I presented previously.
When done, I'll give you a ring so as to verify the sandbox
considerations you mentioned. I don't think they'll be a problem
though because I'm just using shell scripts so far. At most, the
final product will be a tool with framework dependencies no higher
than CoreServices (possibly only CoreFoundation).
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
Democracy: Two wolves and a sheep voting on lunch.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden