Results 1 to 2 of 2

Thread: Known Issues

  1. #1
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Vote Rating

    Default Known Issues

    This is a pre-beta performance preview and has known issues with some components.
    We are expecting some applications to need changes to migrate to 4.1 using this previewespecially if you have written custom layouts and components. This is because we altered some of the low-level architecture of the layout engine, which can have some impact on some more advanced usage of the framework. We will work with you to resolve these issues, and have created a dedicated forum to collect any migration problems you encounter so that we can improve that experience as we approach 4.1 beta.
    I've been playing with 4.1-pr1 for a few hours now and I've run into a number of issues. It's difficult to judge what counts as a 'known issue' and what counts as a 'migration problem' without some guidance as to the known issues. Or would you prefer that we just report everything we find and leave filtering out of the known issues to you?

  2. #2
    Sencha User dongryphon's Avatar
    Join Date
    Jul 2009
    Vote Rating


    Thanks for taking a look so quickly! When in doubt, I would report what you find but...

    Performance of and issues with bringing up the page are most critical. Because we have reworked the rendering and layout process, render events (or methods for custom components) and layout events are worth special mention. We have tried to preserve the timing and semantics of these events, and want to hear about any compatibility issues there.

    After the page loads, interactions are where many known issues reside. Many components have a close connection with their layout logic and need to be tweaked to get along with the new processes. We will be hard at working squashing these bugs after SenchaCon.

    Perhaps the biggest limitation right now in the arena of layouts is an "auto width" component where the width must be read from CSS and is dependent upon its container's size. For example, a width:50% in the CSS or even a width:auto on a panel in an auto layout. The easy workaround for this (until we fix it) is to use the layout of the container to width these children. Such is the typical case anyway, but this is a temporary work around. The portal example uses this kind of sizing for its portlets but we opted to not change the example and instead use it as a test case to verify that we have fixed the core issue here.

    Just to clarify the phrase "auto width": a component that is not configured with a "width" and is also not sized by its owner's layout. These components currently attempt to shrink-wrap around their content, but this is not exactly the desired behavior in all cases (as described above). Shrink wrapping is more complex than the other meaning of "auto width" and was not always reliable in 4.0.
    Don Griffin

    "Use the source, Luke!"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts