I wondered why this never went to the list. ;-) forget again reply-all.
salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
--- Begin Message ---On Sat, 2005-06-11 at 11:09 -0400, Tim Williams wrote: > I've taken my first look at views and this is great stuff. One thing > I don't grasp is how they're "packaged" in the same way that skins > are. They are not, not even close. ;-) We have not yet implemented different skins yet, because we have to finish up and test the default implementation. This said IMO we will focus on that after/on the ApacheCon when we enhanced the underlying design of the plugins. > It seems that if I create customizations in > {project-dir}\src\documentation\resources\templates\*.fv or even That are your project specific implementation of contracts. Here a contract author starts developing new contracts or override default ones. To do it in the project makes the development really fast, because you have the workflow change contract->refresh browser > FORREST_HOME\build\plugins\org.apache.forrest.plugin.output.viewHelper.xhtml\resources > then I'd want to be able to offer those up to someone else in the same > way that skins can be. You *do not* develop contracts there. 1) it is to slow change contract->build plugin->refreh browser 2) this are default contracts If you want to submit new contracts then you will develop them in your project, test them and if you finally happy with them then move them over to the FORREST_HOME\build\plugins \org.apache.forrest.plugin.output.viewHelper.xhtml\resources\templates, test them and submit a patch. > Without a subdirectory for a each named view, I lost you here. > I dont' understand how that happens? Would one just implement another > viewXYZ / viewHelperXYZ plugin combo? *NO* do not copy the combo and try to develop a new skin for views. That is overkill!!! I am thinking about a simple mechanism to enable skin submissions for views under the hood but basically for submitting a skin with view/viewHelper you will need to provide the following resources (* - required): a)* default.fv b)* default.css c) additional-contracts (*.ft) Actually I am thinking about changing the 'default' naming to {skin-name}.fv/css in the matching code, that will enable different skins more easy. ...but IMO everything should go into the default implementation for now. This is still a prototype and will be re-factored latest on ApacheCon. For now I do not concentrate to enable multiple skins under the hood, with the above mentioned resources you can package a skin for views, now and in the future. > Thanks, > --tim HTH and have fun with views ;-) salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
--- End Message ---
