在Flex中使用Spark over Halo有什么缺点?

Man*_*ius 6 apache-flex halo

是否需要更多工作或源代码文件来自定义外观(皮肤)?Spark相对于Halo的可维护性和可读性如何?是否比Halo更高效,更容易定制整体,大约相同,更少?

如果你是一个对Halo外观(可能只是几个CSS调整)99%满意的SDK用户,那么切换到Spark会为你创造更多的工作吗?我们现在需要聘请设计师来获得相当完整的外观和感觉吗?

her*_*ing 2

恕我直言,您可以通过 Spark 皮肤获得更多可能性。因此,在某些情况下,它需要更多的工作,但由于皮肤是可维护的,当然也取决于开发人员。我还没有修改 Halo 皮肤,所以我开始使用 Spark 来处理皮肤。我不是皮肤专家,我只研究过一些皮肤。难度还可以。创建新皮肤似乎很困难,但扩展现有皮肤却相当容易。

如果您 (99%) 满意并且看不到切换到 Spark 的优势,那么您就不应该这样做。

使用 Spark 组件时发生了一些变化,例如 Spark 按钮中不存在在 Button 控件中使用图标的可能性。当然,您可以编写自己的皮肤,并且有更多的可能性来做到这一点,但这需要时间。除了 Button 之外,我并不后悔我们改用 Spark。

  • 如果 Adob​​e 没有极力要求我们不要使用 Halo,我想我会对此感到满意。但由于他们在实际文档中说我们“不应该使用这样那样的”Halo 组件,而应该使用 Spark 组件,这令人担忧。FB 中对 Halo 的支持似乎已成为事后的想法(即使选择 Halo 作为主题,我也无法获得设计模式来显示 Halo 样式),因此 Adob​​e 很难继续使用它。就我个人而言,我不明白为什么我们不能拥有两个并行的组件集,因为 Halo 的设计**可能**在某些用例中工作得更好。 (2认同)
  • 实际上,Adobe 权威使用的措辞(假设您要使用“Canvas”)是“使用spark.components.BorderContainer 代替”。那么如果我们不想怎么办?他们没有解释**为什么**我们应该使用 Spark,并且由于它现在处于“半完成”状态,缺少大量组件,我不太喜欢几乎保证我的系统所需的维护工作和更新的想法。 SDK 5 发布后编写代码。另一方面,如果我们只是永久使用 Halo(假设 Adob​​e 以后不会放弃它,谁知道呢),代码第一次就“完成”了。令人沮丧。 (2认同)