Java GXT FileUploadField的逻辑分析

仅限GXT 3.x

有人能分析并解释FileUploadField中三个私有字段之间的联系吗

具体来说,

触发fileinput显示的按钮的onclick操作在哪里？如果不是在哪里，那么如何

如何将fileinput.getValue（）传输到文本输入小部件

如果你能回答上述问题，你应该能够回答这个问题。。。（如果您没有回答上述两个问题，请不要回答此问题）。下面的陈述是真的，多少是真的还是偶然的

• GXT故意使以编程方式触发按钮onclick变得不可能，因为出于安全考虑，不应允许以编程方式触发文件输入元素
• 如果这是真的，（为什么？）。没有什么能阻止我或任何人

编辑
好的，不要管第2项：fileinput值在onChange方法中被传输到文本输入

没有。在“真实”按钮的顶部有一个不可见的

。当您单击此按钮时，会出现对话框-单击“hit”按钮是

，而不是按钮，但是

onBrowserEvent

告诉按钮的行为与单击按钮的行为相同。据我所知，这是访问浏览器提供的文件系统（即“选择文件”）的唯一方法（至少支持没有新文件api、flash或其他插件的浏览器）

向页面上的javascript公开对名称的访问（可能是完整的，也可能不是真实的）。正如您所注意到的，这在输入本身的DOM更改事件中可用。只有文件名可用（同样，没有文件api），它可能有一个假路径（即IE）或没有路径（其他所有人）

这不是GXT所关心的安全问题——相反，字段dom的rube goldberg布局是为了处理浏览器的安全限制。在

上使用

private

只是为了明确您不应该直接访问它，并且对阻止您阅读它没有任何意义。如果您将其子类化，请在

getFileInput（）

之后进行操作，否则，请使用JSNI和所谓的violator模式获取对文件字段或该方法的引用

是的，这不是关于安全性，而是关于编写可维护的代码。另见

---

现在，在解释了该方案的简单性之后，我觉得自己真的很愚蠢，而且这似乎是一种公认的/标准的做法，可以克服浏览器对文件输入元素的限制。但我真正想做的是让fileuploadfield由enter键触发，而不是鼠标点击。如何使文件输入元素容易受到enter键的影响？好问题-技巧在于聚焦文件输入，而不是按钮，因为它需要用户直接与文件输入交互，才能使其启动。我不知道是否可以通过编程方式对文件输入调用

focus（）

，需要对其进行测试。文件输入无法访问，因为其tabindex设置为-1。