Scott Eade wrote: >Good call. I believe that Henning has enhanced the fulcrum intake service >to support multiple intake.xml files. He has indicated that he is happy to >provide read-only public cvs access to this code, but he may need a little >prompting to follow through on this offer. > >Cheers, > >Scott > > I am still holding off trying to use the fulcrum and the component mechanism. Previously I heard things about it's going to be deprecated in future Turbine. It scared me off. Anyway, I feel like Turbine is in a somewhat in a limbo state right now. The 2.2 release has been dormant for a long time and there isn't much activity going into the coupled services. I imagine much of the code is going into fulcrum but it seems that's is going to change in the future (!). I don't know when or whether I want to dive my head into the fulcrum world yet.
I've been using the coupled intake extensively with an i18nized app. From what I see there can be much improvement in that area. Don't get me wrong, intake is a great thing, but there are several things that can make it better. For example, the multiple file/module support for intake would be nice. I would also like to have a more extensible intake that takes in Collection values (like List) without resorting to use multiple groups. Sometimes I would just like to get/set a List of strings, for example, without creating a group for each individual string, assign the id, and go from there... Also I would like to write my own validator for a value for things that requires backend server validation (like validating a hostname), a real RFC 822 parser for email address, etc. Furthermore, a better error message mechanism is needed. Right now, I can't really substitute the wrong variable in the error string very easily using intake. For example, I can't output a message like "Your input value of X is too large", where X is the value that you put in. On top of that, I would like to output the error message in a i18n manner (I'm currently using the i18n tool to do the trick). I myself have peeked in the coupled intake code multiple times using a debugger, and I can say I have a fair understanding in how intake works internally. However, if I want to make my own extensions and contribute something back to Turbine, I am not sure how. I think a much clearer direction for Turbine is necessary for people like me to contribute something back to an excellent code base. The question is how, when, and where. Will -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
