Re: Re: Roadmap?

I for one, would be very interested to hear more about all of this. We are about to start some development to re-write our major UI that fronts an XML web service and I would like to end up with something that is dynamic and can easily be configured on a per client basis but is tightly integrated to the XML. I will be playing with some similar ideas very shortly. I would just love to end up with some "drag n droppable" kit, but I don't have the extensive knoweldge of barracuda's inner workings that some of you do. Anyway, i'm up for the discussion and would love to chip in if i can. I guess my timescale is a very tight (as always!), but maybe i'll just work out how not to do it! ;)

Adam.
  ----- Original Message ----- 
  From: Srinivas Yermal 
  To: [email protected] 
  Sent: Monday, December 01, 2003 10:42 PM
  Subject: Re: [Barracuda] Re: Roadmap?


  Hi,

  Thorsten, could you please talk a lil' more about how these components behave? I do understand BImage and BImageLink to an extent...

  I was talking more in terms of a layer between the actual view and the component view, or an external way to bind behavior into my applications. Another way to look at it I think, is to somehow have events tied to components externally and not in the code. I feel that there is a need for the separation of the components and their function, and the handler code. This could very well be a layer over the currently existing component layer and event layer. Bringing the two important barracuda pieces externally instead of code. This will also make way for a "drag-and-drop" solution to create a component frame/screen which can then be tied to handler code. 

  The context of all this is when you have to deal with enterprise web-application products which need to be tailored to the customer and her goals. And at the same time not maintain as many branches of the code as the number of customers you have.
  For example, when I add a component (say BAction) to the screen the behavior becomes a part of the model that you add to the view. So minor changes to the view will now require changes to the code.

  Another idea is giving generic behavior to the components themselves and make them a lil more intelligent like a BInput being able to say whether that input is mandatory or not, and the validation process being able to handle it, just by specifying the component in an xml file which is read during the startup to construct the abstract view. All this I think, can be built with existing framework, and I am not sure whether it can become a part of barracuda (more like an add-on) or whether it is in-line with the barracuda's vision. Hence the question on Roadmap. 

  I dont know whether I am clear enough in my thought process. Please feel free to comment.
  Thanks,
  Srini.

  Thorsten Möller wrote:

Srinivas Yermal <[email protected]> wrote:

  
3. Not enough components and the ease of use of components.
    
Maybe you are interested in this: I'm working on seven new Components:
BFrame, BImage, BImageLink, BLogin, BMenu, BMessage, BSubstitutor. They
follow the concept "no directives and code in markup but freedom of design".
Except for BSubstitutor (lightwight BTemplate) where I use one very easy
directive this is true. Provided that the Barracuda community is interested
on them, I would contribute them to the project.
At the moment they work, but they have small limitations which must be
improved and more tests are needed to make them stable. Also the
documentation is poor and must be completed.

Regards,
Thorsten

_______________________________________________
Barracuda mailing list
[email protected]
http://barracudamvc.org/lists/listinfo/barracuda