问题标签 [catalog]

我正在使用兼容 OASIS v 1.1 的解析器（Norm Walsh 的XMLResolver以及下面的目录。但是，我很确定我在这里犯了某种明显的错误（这是我第一次需要使用v 1.1 features)，因为尝试解决 OxChapML.dtd 失败。任何人都可以看到明显的错误吗？甚至是微妙的错误？

更新：使用元素上的集合，所有public元素都可以很好地解析。只有那些应该使用失败的元素来解决的元素。因此，如果我有一个使用 PUBLIC 标识符声明其 DocType 的文档，它将毫无问题地解决（我的 CatalogManager.properties 中有一个设置）。但是，如果我只有一个 SYSTEM 标识符（例如“OxChapML.dtd”），这应该与适当的匹配，但事实并非如此。在解析器上打开调试表明它甚至没有尝试通过.xml:basegroupsystemSuffixprefer=publicsystemSuffixsystemSuffix

您能否推荐一个用于 Wordpress 的插件或一个小型的独立 PHP 脚本，它允许用户将一些带有文本信息和照片的项目添加到数据库、XML 或只是来自特殊管理页面的文本文件？我需要从源中获取这些项目并以某种方式显示在页面中。为了更好地理解任务，请查看此页面。有一个显示项目的主要区域，但现在它只是虚拟 HTML，看看它最终应该是什么样子。

谢谢！

有很多方法，这有点令人困惑，但在 Magento 1.4 产品目录中更改默认网格列的最佳方法是什么？

谢谢

我为产品创建了一个新的是/否属性。我已经扩展了 Product 模型来执行一些自定义逻辑，并且自定义函数无处不在。

当我最初尝试获取自定义属性值时，我遇到了一些问题。Magento 没有为我加载它，所以调用 $product->getMyAttributeName() 什么也没做。在产品视图中，我使用了这个附加功能：

因此，在前端查看产品时效果很好。如果设置，它将获取分配的值，否则将获取默认值。

当我查看任何类别（该类别中所有产品的网格）时，正在执行相同的确切代码。但是我的 getAttrVal() 函数总是返回默认值，即使我已经为我的产品明确设置了这个值。

在我的一生中，我无法弄清楚为什么属性在产品视图中正确加载，但类别视图总是获取默认值，尽管运行相同的确切代码。有什么想法吗？

我正在使用 Apache Web 服务 xml rpc 库向 rpc 服务发出请求。在该过程中的某处是一个 xml 文档，其中包含对http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd的 DTD 引用，该库在解析 XML 时尝试下载该文档。该下载失败并显示 503 状态代码，因为 w3c 正在阻止从 Java 客户端重复下载这个基本上是静态的文档。

解决方案是在本地缓存 DTD 的 XML 目录。但是，虽然我可以找到直接在 JAXP SAXParser 实例上设置 EntityHandler 以启用目录解析器支持的示例，但我实际上无法访问此处的底层解析器。它只是被 xml rpc 库使用。有什么方法可以设置全局属性或告诉 JAXP 使用 XML 目录的东西吗？

我正在寻找软件的常见错误、弱点和测试用例或问题的目录。在“软件测试经验教训”中，我看到了一个示例测试目录，但我通常找不到针对各种常见功能或功能类型的好的、特定的测试目录。有人可以指出我的资源吗？

也许一个关于 SO 的社区 wiki 会是有序的？

以下是一些用于测试用例目录的社区 wiki：

• 数字输入测试目录
• 文本输入测试目录

What are some common (or worthwhile) tests, test questions, weaknesses, or misunderstandings dealing with numeric inputs?

This is a community wiki. Please add to it.

For example, here are a couple sample ideas:

• I commonly see users enter text into number fields (eg, ">4" or "4 days", etc).
• Fields left blank (null)
• Very long numeric strings
• Multiple decimals and commas (eg, "4..4" and "4,,434.4.4")
• Boundary Value Analysis:
  • Lower Boundary
  • Lower Boundary - 1 (for decimal/float, use smaller amounts)
  • Upper Boundary
  • Upper Boundary + 1
  • Far below the lower boundary (eg, beyond the hardware boundary value)
  • Far above the upper boundary
  • middle of the range
• 0
• 0.0
• White space, nothing else " "
• String input & other incorrect data types.
• Number with text in front or back, eg "$5.00", "4 lbs", "about 60", "50+"
• Negative numbers
• + sign with positive numbers, "+4"
• Both plus and minus sign, eg "+-4" and "-4e+30"
• Exponents of 10, both uppercase and lowercase, positive and negative eg "4e10", "-5E-10", "+6e+60", etc
• Too many "e" characters, eg "4e4e4" "4EE4"
• Impossibly large/small exponents or inappropriate ones
• Decimal values that cannot be represented in a computer
  • eg, .3 + .6 == 1.0? This bug affects most hardware, so outputs that compare decimal values should allow for a degree of error.
• Integer/hardware overflow. Eg, for 32-bit integers, what happens when adding 4 billion to 4 billion?
• wrong use of decimal sign and thousands seperator ("," vs. ".") (MikeD)
• internationalisation i18n issues: In english aplications you write "12,345.67" meaning "12345.67" in german you write "12345,67" – (k3b)
• leading 0's don't make number octal (common javascript bug)

很快，我将致力于支持多语言内容的目录（php+mysql）。现在我正在考虑设计数据库结构的最佳方法。目前我看到了多语言处理的 3 种方法：

1) 为每种语言特定的数据提供单独的表格，即示意图如下所示：

• 将有一个表Main_Content_Items，存储无法翻译的基本数据，例如 ID、creation_date、hits、votes 等等 - 它只有一个，并且将引用所有语言。

以下是将为每种语言复制的表格：

• Common_Data_LANG 表（例如：common_data_en_us）（存储可以翻译的通用/“静态”字段，但存在于任何目录项中：标题、描述等...）
• Extra_Fields_Data_LANG 表（存储可以翻译的额外字段数据，但对于自定义项目组可以不同，即：| id | item_id | field_type | value | ...）然后根据项目请求，我们将根据用户/默认语言并将可翻译数据与main_content表连接。

优点：

• 我们可以只用一个查询更新最常更新的“主要”数据（即点击数、投票数……）
• 如果我们有 4 种或更多语言，与仅使用一个带有“lang”字段的表的结构相比，我们不需要重复数据 4 倍或更多次。因此，MySql 查询将花费更少的时间来通过 100000（例如）记录目录而不是 400000 或更多

缺点：

• 每种语言+2个表格

2) 在内容表中使用“lang”字段：

• Main_Content_Items 表（存储无法翻译的基本数据，如 ID、creation_date、hits、votes 等...）
• Common_Data 表（存储可翻译的通用/“静态”字段，但存在于任何目录项中：| id | item_id | lang | title | desc | 等等...）
• Extra_Fields_Data 表（存储可以翻译的额外字段数据，但对于自定义项目组可以不同，即：| id | item_id | lang | field_type | value | ...）所以我们将common_data和extra_fields连接到main_content_items到 'lang' 字段。

优点：

• 我们可以只用一个查询更新最常更新的“主要”数据（即点击数、投票数……）
• 我们只有 3 个内容数据表

缺点：

• 我们有 custom_data 和 extra_fields 表填充了所有语言的数据，所以它的 X 时间更大并且查询运行更慢

3) 与第二种方式相同，但 Main_Content_Items 表与 Common_Data 合并，具有“lang”字段：

优点：

• ...？

缺点：

• 我们需要更新最常更新的更新“主要”数据（即点击数、投票数......）
• 我们有 custom_data 和 extra_fields 表填充了所有语言的数据，所以它的 X 时间更大并且查询运行更慢

会很高兴听到关于“什么更好”和“为什么”的建议？还是有更好的方法？

提前致谢...

我想确保我不会在我当前的项目中重新发明轮子。我正在编写一个为 CAD 程序创建内容目录的工具，该程序对文件进行编目。

我的Catalog类代表文件和文件夹的层次结构。目录中的文件可以存储其他元数据，这些元数据不应修改实际文件。此元数据还可以包括其他文件，例如缩略图或附件。目录为典型的 CRUD 交互提供了一个接口，并且还应该允许文件（连同它们的元数据）在目录之间进行复制。

我正在尝试将接口抽象为目录，使其几乎可以存储在任何地方。例如，现在我正在创建一种存储在文件系统上的目录格式。缩略图和附件等元数据文件存储在目录文件夹内的边车文件中，其余目录数据存储在目录文件夹根目录的 XML 文件中。但是，我正在尝试将 Catalog 类抽象到可以创建存储在 SQL Server、HTTP 服务器、ZIP 文件、二进制文件等中的版本的程度。

因此，我使用 System.IO.Stream 作为二进制数据的最抽象表示，而不是通过磁盘路径引用文件。最终，我希望能够创建一个拖放界面，用户可以在其中在任何格式的目录之间移动文件。这变得相当复杂，因为在目录之间移动文件还需要移动相关的元数据文件。因此，我还试图找出一个事务系统，以确保所有或没有请求的文件 IO 操作完成。

我的 IDatalog 界面如下所示，以供参考。希望它能更好地了解我正在努力完成的工作。所以无论如何，现在我想知道我是否在重新发明轮子，或者是否有任何现有的工具或库提供类似的功能。

在我们的应用程序中，我们有一个包含事物的存储库（它们被称为方法和查询，但这与这个问题并不特别相关）。每件事都有一个标题、描述（尽管有些可能两者都没有）和一些其他数据。用户将事物保存到存储库并从存储库加载和使用事物。

我想知道从可用性的角度组织存储库的最佳方式是什么。似乎有两种主要方法。第一种方法是将东西放在文件夹、子文件夹等中，并具有类似于文件系统的层次结构。第二种方法（已成为时尚）是两个具有平坦空间并为每个事物分配零个或多个标签，以便用户可以查看特定标签的事物列表。

目前我们使用平面空间、标签和搜索。似乎有些难以驾驭。我不确定切换到文件夹/子文件夹是否会更好。

我想更多地了解每种方法的优缺点以及集合的哪些属性以及事物本身建议使用一种或另一种方法或两者的组合。如果有人能指出我对这些的一些研究或讨论，我将不胜感激。