用于基于组件(或复合)的 Web 应用程序的 OpenRasta 框架
我们正在尝试构建一个更加松散耦合的基于组合的 Web 应用程序,并研究各种选项和框架。
这个想法就像当用户浏览到一个页面时,将在服务器上解析 uri,以获取资源以及根据配置采取的操作列表。
该视图将由一些 html 标记和一些基于其他 URI 内容的组件组成。这些组件是可重用的,并且彼此之间不应该有任何想法(也许是上下文)。
这只是一个想法,我想看看 OpenRasta 框架将如何帮助解决这个问题。我的方法可能完全错误;也许使用当前的 ASP.NET WebForm 和 MVC 框架可以轻松完成此操作,但我想看看您的意见。
we are trying to build a more loosely coupled composite based web application, and looking at various options and frameworks.
The idea is like when the user browse to a page, the uri will be resolved on the server for a resource and a list of actions to take based on the configuration.
The view will be composed by some html markups and some components that are based on other URIs for their contents. The components are reusable and should not have any ideas about each other (maybe the context).
this is just an idea, and wanna see how the OpenRasta framework would help on this. I might be completely wrong with the approach; maybe this can be easily done with current asp.net webform and mvc framework, but i would like to see your opinion.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我刚刚完成了一个 OpenRasta 站点,该站点依赖于我注入视图中的标准 Web 控件,传递强类型资源(由 OR 通过处理程序提供)以使控件能够以通常的方式显示资源属性等。
资源实例携带要加载和注入的控件的路径(Resource.ControlPath)。这是通过连接 URI 的各个方面来查找控件来在处理程序中设置的。这允许不同的 URI 请求位于站点文件层次结构中不同位置的同一控件的不同版本。
例如,ClientA 需要一个包含大量特定于客户的文本和功能的介绍视图。 ClientB 还需要一个具有不同内容和功能的介绍页面。
这给出了两个 URI
Configuration
IntroHandler.cs
Intro.aspx
Intro.ascx
Intro.ascx.cs
因此,每个版本的介绍控件都通过客户端特定功能扩展了视图。
I have just completed an OpenRasta site that relies on standard webcontrols that I inject into my views, passing on the strongly typed Resource (supplied by OR via the handler) to enable the control to surface resource properties etc in the usual way.
The resource instance carries the path to the control to be loaded and injected (Resource.ControlPath). This is set in the handler by concatenating aspects of the URI to find the control. This allows different URIs to request different versions of the same control that live at different locations in the site file hierarchy.
So, for example, ClientA requires an intro view with lots of client-specific text and features. ClientB also requires an intro page with different content and features.
This give two URIs
Configuration
IntroHandler.cs
Intro.aspx
Intro.ascx
Intro.ascx.cs
Therefore each version of the intro control extends the View with client specific features.