Le 23 oct. 06 à 21:05, Yen-Ju Chen a écrit :
On 10/23/06, Guenther Noack <[EMAIL PROTECTED]> wrote:
- Making the code modular
There should be modules (best: bundles) that provide one
NSView
each that can be put into one of the three panes in the three
pane view. The application should communicate with the
bundles
through the bundle controller only. Bundles can also
communicate
using the NotificationCenter. Every bundle has methods to
get a
set of articles as input and can output articles using
notifications. The three loaded bundles are then put into a
"chain" where each one has a subset of its input as the
output.
The first bundle has the whole set of articles as input.
As I'm currently working on the terminal, here's a rough
sketch
in ASCII:
+----------------+-----------------------------------+
| | |
| Bundle 1 of 3 | Bundle 2 of 3 |
| | |
| input: all | input: output from Bundle 1 |
| available | output: subset of input |
| articles | |
| | |
| output: subset | |
| of input +-----------------------------------+
| | |
| | Bundle 3 |
| | input: output from Bundle 2 |
| | output: none, it just displays |
| | the first article in the input set |
+----------------+-----------------------------------+
I think such architecture could be prove to be interesting.
I had something similar in mind when I wrote the components page on
Étoilé wiki.
You asked some explanations about this component approach few weeks
ago. I never replied and I'm sorry for having stayed silent on this
subject. At some point, I plan to dig into this again.
What you describe is quite close to what I mean but at an application
level, therefore in a less generic way. Below are some comments on
the referred page <http://www.etoile-project.org/etoile/mediawiki/
index.php?title=ComponentKit>
By 'Stream' (input or output), I mean dedicated objects to represent
input or output. In your explanation, this role is played by a bundle
object.
By 'Behavioral', I mean an object that for example takes a list in
input and returns a selection of objects in the list. This is
basically a simple 'search' component. You could have a different
behavioral component which takes the same list in input but returns a
tree. I think you got the idea :-) This role is played by bundle
object in your explanation again.
By 'Structural', I mean an object to represent any kind of object
collection which can play the role of a data source. This could be an
array, a dictionary, a database, a file system etc. In Grr case, this
role is handled RSSKit storage model I think. This storage model is a
property list iirc.
By 'Visual', I mean a view object that can be replaced by another one
on the fly. For example, you can replace an icon view by a list view.
This role is played by Bundle view object in Grr case.
By 'Pipe', I mean an object to represent a connection between two
components exchanging data.
This a very fine-grained approach. For example… Most of time
'behavorial' or 'strutuctural' components can play the 'stream' role
themselves. A distinct 'stream' abstraction could be useful in the
same way NSStream and related classes are. Moreover having a special
'pipe' object to represent connections is superfluous I think.
The modular system is kind-of over kill to me, at least for present.
Maybe we can think about it for the next major version after this.
The way I am thinking is that you need a modular system only
when you want to reuse ths code.
Currently I haven't thought about any other application to use the
same architecture.
If you abstract it a bit more, many applications have a potential
interest in such architecture In fact it's in part the idea behind
Cocoa bindings, though Apple design is quite complex, thereby has no
support to swap an element on the fly and is implemented by adding an
extra layer rather than trying to simplify the current oddities in
AppKit API. Anyway I agree it isn't that easy and it won't be the
perfect fit for many applications.
As for the notification, I personally perfer to use it as less as
possible
because it is harder to debug.
When a notification is posted,
it is not obvious which objects will recevie the notification.
Therefore, when I found a bug related to a notification, it is
harder to find
the source and destination.
True.
I use it only when I need to notify several objects at the same time,
or when some actions has unknown returned time, such as loading in
background.
If the chain of reactions is straight and the targets are known,
I prefer not to use notification.
Notifications are useful for preference modifications too and they
aren't always a bad choice for propagating model changes.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
