FROM : Erik Buck
DATE : Sun Nov 04 02:10:31 2007
--- Uli Kusterer <witness.of.<email_removed>> wrote:
[Deleted]
> It seems perverse to me that someone would want to
> use NIBs in a
> team of more than three developers, while you're
> effectively
> blindfolded and can't even do a "code review" of the
> NIB changes
> another developer did.
>
I agree.
If you have more than three developers who need to
edit a single nib file, you have a serious problem.
Sometimes the problem can be mitigated by having lots
of small nibs, but that isn't always possible or
desirable.
I admit, that most projects I have directly
experienced have had ten or fewer software developers
at any moment in time. There might have been fifty
developers in the lifetime of an application, but not
all at once. Of the ten concurrent developers, the
usual number of GUI developers is exactly one.
Frequently, large/complex applications are designed
and developed with back end frameworks split over
multiple teams and thin GUIs (using MVC).
In another post, Uli observed that locks don't help
when you're working with branches, because then NIBs
are impossible to merge back if someone changes
something in the trunk.
Uli makes a very valid point! I think we need a human
readable and computer merge-able way of viewing the
target-action, bindings, and layout/nesting details of
a nib. This is essential even just to document the
design of a nib. It is too difficult to figure out
how somebody else's nib is put together right now.
I don't think these problems with IB and nibs raise to
the level where I would prefer to hard code all
aspects of a GUI.
DATE : Sun Nov 04 02:10:31 2007
--- Uli Kusterer <witness.of.<email_removed>> wrote:
[Deleted]
> It seems perverse to me that someone would want to
> use NIBs in a
> team of more than three developers, while you're
> effectively
> blindfolded and can't even do a "code review" of the
> NIB changes
> another developer did.
>
I agree.
If you have more than three developers who need to
edit a single nib file, you have a serious problem.
Sometimes the problem can be mitigated by having lots
of small nibs, but that isn't always possible or
desirable.
I admit, that most projects I have directly
experienced have had ten or fewer software developers
at any moment in time. There might have been fifty
developers in the lifetime of an application, but not
all at once. Of the ten concurrent developers, the
usual number of GUI developers is exactly one.
Frequently, large/complex applications are designed
and developed with back end frameworks split over
multiple teams and thin GUIs (using MVC).
In another post, Uli observed that locks don't help
when you're working with branches, because then NIBs
are impossible to merge back if someone changes
something in the trunk.
Uli makes a very valid point! I think we need a human
readable and computer merge-able way of viewing the
target-action, bindings, and layout/nesting details of
a nib. This is essential even just to document the
design of a nib. It is too difficult to figure out
how somebody else's nib is put together right now.
I don't think these problems with IB and nibs raise to
the level where I would prefer to hard code all
aspects of a GUI.






Cocoa mail archive

